The extractor (executed for a module only) creates .pot files and include strings already defined in core. This will end in different translations of different non-core modules and my "Cancel" button will be badly changed into "cancel" and such other examples.

If i execute the extractor in my webroot the "general.pot" file will include non-core module strings - only existing in a contributed module. So i'm made to extract the contributed module strings all by hand (???), what is much much work and an error prone way. Additional if a file contains less then 10 strings it will be included in "general.pot", too. This makes no sense for a module translation that should be definitively separated into modules directory. This is very bad and i'd like to prevent this for module translations.

Please explain - how we are able to create .pot files for non-core modules *without* core strings.

Comments

cog.rusty’s picture

cog.rusty commented

To "work with the system" as it is:

- For extracting strings, I do it separately for core and for each contributed module, in a separate directory structure similar to the one in CVS. So, the modules are not in subdirectories of core.

- For not overwriting core during import, I let contributed modules have duplicates of the core strings. In /admin/settings/locale/language/import there is an option "Existing strings are kept, only new strings are added"

Is there something which cannot be done this way? Or does any of these steps involve much unnecessary work?

hass’s picture

hass commented

For not overwriting core during import, I let contributed modules have duplicates of the core strings. In /admin/settings/locale/language/import there is an option "Existing strings are kept, only new strings are added"

The problem is, i cannot change the behavior of autolocale module. This one does 'overwrite' everytime and i cannot change this. From the logic how autolocale search for translation files it looks not easy to change this behavior. Therefor it will be easier and in general better to not include strings already in core another time in a decentralized module POT!??? This ends with people doing the this same translation jobs more then once and this will result in duplicate strings and duplicated work, while a module translator may forget so search inside a [de].po file if the string xyz has already translated in core or not and then copy a found string over inside the module translation.

This sounds and i feel this like senseless work for me - nothing else.

cog.rusty’s picture

cog.rusty commented

Hmm... that would require that the pot extractor takes into account the core strings for the particular core release used on a site.

Since the option not to overwrite existing strings does exist, isn't it more practical to make this a feature request for the autolocale module, at least for now.

cog.rusty’s picture

cog.rusty commented

I just saw the two issues you have submitted for autolocale. As I suspected, removing the core strings from the po files was considered not possible.

But it seems to me possible to introduce autolocale options for "non-overwritable" or weighted module translations. A while back I noticed that information about "where this string comes from" was kept in the database (not sure if this is still the case).

hass’s picture

hass commented

i played the whole day with msgcat and the other msg* tools and haven't found a way to do for e.g. merge files x, y, z together, but ignore all strings inside "de.pot". So i think this should be addressed in autolocale - but i don't know how long this takes to get inside and i really really need this for finishing a multilingual installer profile...

additional i committed a bugfix for cck's "de.pot" to solve my current problems, but it's really more like a general question - if a module should have the same strings already inside core. i think not, while nobody will import a modules locale files and not core... everything else sounds strange.

cog.rusty’s picture

cog.rusty commented

What you tried with msgcat does not seem impossible, but I think it is not enough. The user of a site may have custom strings which shouldn't be overwritten by autolocale.

gábor hojtsy’s picture

gábor hojtsy
he/him
Primary language Hungarian
Location Hungary
commented
Status: Active » Closed (won't fix)

Let's state that this issue deals with generated .pot files without core strings. Other issues with autolocale or any other module or translation does not belong in here.

Generating module .pot files without core strings is unfortunately not possible. You would need a .pot of the corresponding core version, against which you do your contrib module translation. But Drupal core strings change, even in point versions, so we would need to know exactly what version we work against. But users will not necessarily use that version on their site, so we cannot accurately identify these strings. (Plus it also happens that most of the time, an accurate reference string list is not available, when someone generates strings for a module).

hass’s picture

hass commented

Good point... ok, i have fixed cck to be in sync with core and now the overwrite method in autolocale is no problem any more.

wwwoliondorcom’s picture

wwwoliondorcom commented

Hello,

When importing language can you tell me what I should choose ?

Strings in the uploaded file replace existing ones, new ones are added
or
Existing strings are kept, only new strings are added

Thank you.