Drupal Webform CiviCRM Integration in french

[JMM]

Hi,

I try to implement Drupal Webform CiviCRM Integration in french (webform_civicrm Module)
I have localized (in french) Drupal and CiviCRM, and everything seems OK
I have also installed webform_civicrm, and webform localization : install looks correct

Problem : when I want to create a Webform, based upon CiviCRM, everything remains displayed in english (including CiviCRM field names : e.g. First Name, Last Name, instead of Prénom, Nom) : CiviCRM Webform is not localized (though CiviCRM is)

Of course, I could re-translate all field names, using Translate Strings, but I don't feel it like a good practice : I must have missed something.

Any help would be welcome : thanks in advance

FYI, I enclose a screen copy of my Drupal Tree structure

[mathieu]

Hi,

From what I can see while doing a quick test, webform_civicrm uses the t() function of Drupal to translate strings, so this fetches strings from a separate translation file.

You can download the strings using the l10n_update module, but the translation is not complete for French. You can also help improve the translation from: https://localize.drupal.org/translate/projects/webform_civicrm (you have to join the French translation team first: https://localize.drupal.org/translate/languages/fr).

Mathieu

[JMM]

Hi Mathieu (BTW, a french first name ?)

Thank you for your answer.

"separate translation file" : do you mean different from the installed i10n or i18n ?

Anyway, I will try to follow your suggestions, ... and keep you informed

Thanks again

[mathieu]

Separate file in that the translations for webform_civicrm are in another location. So a string might seem translated in CiviCRM, but not translated in webform_civicrm, because it is using translations from another source, i.e. translations from localize.drupal.org, which must be downloaded with l10n_update (or manually). Also, like any module, not all strings may have been translated, since it depends on volunteer translations from users like us.

Sorry if I'm not clear, it would be easier for me to express as a drawing.. (maybe I'll do that when I have a moment)

Et oui, je suis de Montréal/QC

[JMM]

Thanks for your precisions, which clarify somehow.

Actually, a drawing would help a lot : I agree.

Bonjour le Quebec et merci encore (I have been in Montreal some years ago for business and I have a nephew living there : I love this town).

[Coleman Watts]

mathieu - can you think of something I ought to be doing differently in webform_civicrm - like does CiviCRM provide a way of getting localized field names? I suppose I could do ts('State/Province') instead of t('State/Province') but maybe there's an even cleaner way fetching if from the schema and not using a string literal at all?

[mathieu]

I'm not very familiar with the schema, would there be a unified way of getting the label for State/Province, as well a custom fields (which can have multi-lingual labels)?

I have mixed feelings on using ts() instead of t():

* ts() : would require sending the module code to Transifex, as for native civicrm extensions; would also require that ts() know where to load the .mo file (works OK for native extensions, but might not be obvious for Drupal modules).
* t() : translation effort duplication, strings do not go through the "string replacements" (particularly useful for State/Province, which is probably often overriden).

[Coleman Watts]

I was thinking something like:
- use ts() for CiviCRM terminology where the string is already in Civi (like field labels).
- use t() for the drupally strings and stuff specific to the Webform-Integration UI.

I was just wondering if there isn't an even better way to get the field labels. But that aside, what do you think of the above?