Hi,
I think it would be a good feature to be able to import translations in local files into different string groups (such as for example the "Field" string group). This would be useful when building feature modules which require translations of field labels or descriptions.
Local files could be stored under the translations directory with a name such as %project-%release.%group.%language.po.
The question would therefore be how to implement the importation of such files to the right group with l10n_update. I'm going to start working on a patch for this but, meanwhile, if anybody has ideas/suggestions for this feel free to let me know...
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | l10n_update-add_textgroup_support-1421600-11.patch | 6.8 KB | FreekVR |
| #11 | l10n_update-add_textgroup_support-1421600-10.patch | 6.71 KB | FreekVR |
| #7 | 1421600-text_groups-7.patch | 3.44 KB | guillaumev |
| #6 | 1421600-text_groups-2.patch | 3.29 KB | guillaumev |
| #5 | 1421600-text_groups-1.patch | 3.03 KB | guillaumev |
Comments
Comment #1
sutharsan commentedI don't understand your concept of string groups. What problem do you try to solve? Do you mean Textgroups? If so, you're too late, its dead: #1188430: Rip out textgroup support from locale module
Comment #2
gábor hojtsyTextgroups are going away in Drupal 8, but they are used extensively in D7 to handle all kinds of config translation.
Comment #3
guillaumev commentedHi,
I'm creating an installation profile where I have some default fields defined with titles in English. I'd like the installation profile to automatically pick up the translation of these field titles.
Unfortunately, currently, there is no way to do this, since importing (programmatically) through l10n_update automatically imports in the "Built-in interface" textgroup.
I didn't know that textgroups were going to go away in Drupal 8 (which I think is not a bad thing), but still, it doesn't solve the issue for D7... I will see if I can propose something, but again if someone has ideas :-)
Comment #4
bforchhammer commentedI have the same problem... I have a set of features which contain content types and fields, and a custom l10n_server setup for translations; I can translate easily with the l10n_client module, but updating only works for interface strings ("Build-in interface"); field label translations are ignored, which means that I have to import them manually... (this kindof defeats the purpose of having a translation server, i.e. automatically handling translation updates).
Function
l10n_update_import_file()calls_l10n_update_locale_import_po()always with the text-group parameter set to "default", so that's where this would probably need to be changed... before that we would of course need to determine the correct textgroup somehow.Comment #5
guillaumev commentedHere is a first patch which needs some testing.
The proper text group is determined by the comment that comes before the msgctxt, so for example when parsing something like that:
the string will be imported in the "field" textgroup. For all the other strings, which either don't have comments or where a group can not be determined, the default textgroup will be used...
This patch worked quite well for me so far, but requires manual edits of .po files generated by l10n_server. I'm working on a patch for l10n_server that would avoid these manual edits...
Comment #6
guillaumev commentedProviding a new patch (a bit more robust) for this and I also would like to link to the following comment: http://drupal.org/node/1227734#comment-6117792 where I'm providing a patch for l10n_server which will allow you to create .po files in the proper format to be able to import into the right textgroups...
Comment #7
guillaumev commentedNew patch which fixes a bug when importing.
Comment #8
FreekVR commentedThe patch in #7 works great for my fields export. I will be testing some other export types, but the fact that it checks if the group is found exists seems to make it pretty dependable to me.
The use case why we need this in our case; We're building a platform which will be deployed in multiple languages in the future. We want to have automated, code-driven, translations for field labels and the like (using i18n) but have developers always input the defaults in English, since developers may not master the language(s) the site will actually be deployed in. Field exports can be maintained by either the client or someone else who does master the language in question.
As such I've created a couple of "fake projects" using hook_i18n_projects_alter where these field translations are being imported from - and using the patch provided also into the right text group.
Comment #9
idebr commentedConsidering #1188430: Rip out textgroup support from locale module and l10n_update 7.x-2.x is a backport of the Drupal 8 version, I suppose support for Text Groups will not make in to the 7.x-2.x version?
For illustration, check the hook_schema implementation of locales_sources in Drupal 7.x vs Drupal 8.x:
7.x: http://cgit.drupalcode.org/drupal/tree/core/modules/locale/locale.instal...
8.x: http://cgit.drupalcode.org/drupal/tree/modules/locale/locale.install?h=7...
Comment #10
FreekVR commentedHere's a port of the textgroup patch for 7.x-2.x.
Note that unless you use i18n_string, all items will still be imported into the 'default' textgroup.
Comment #11
FreekVR commentedLet's rename the getters/setters to correspond to the property name.
Comment #12
sutharsan commentedThe code looks good. I will add it to the 7.x-2.x version, but only after the 7.x-2.0 release.
Comment #13
sutharsan commentedThanks all.