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...

Comments

sutharsan’s picture

Status: Active » Postponed (maintainer needs more info)

I 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

gábor hojtsy’s picture

Textgroups are going away in Drupal 8, but they are used extensively in D7 to handle all kinds of config translation.

guillaumev’s picture

Status: Postponed (maintainer needs more info) » Active

Hi,

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 :-)

bforchhammer’s picture

I 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.

guillaumev’s picture

Status: Active » Needs review
StatusFileSize
new3.03 KB

Here 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:

#: field:field_tags:audio:label
msgctxt "field_tags:audio:label"
msgid "Tags"
msgstr ""

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...

guillaumev’s picture

StatusFileSize
new3.29 KB

Providing 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...

guillaumev’s picture

StatusFileSize
new3.44 KB

New patch which fixes a bug when importing.

FreekVR’s picture

Issue summary: View changes

The 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.

idebr’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev

Considering #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...

FreekVR’s picture

Here'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.

FreekVR’s picture

StatusFileSize
new6.71 KB
new6.8 KB

Let's rename the getters/setters to correspond to the property name.

sutharsan’s picture

Status: Needs review » Reviewed & tested by the community

The code looks good. I will add it to the 7.x-2.x version, but only after the 7.x-2.0 release.

sutharsan’s picture

Status: Reviewed & tested by the community » Fixed

Thanks all.

  • Sutharsan committed 5938e39 on 7.x-2.x
    Issue #1421600 by guillaumev, FreekVR: Added Importing into different...

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.