Come up with better PO file set/placement

How are they different?

What .pot file set do you compare with? Can you provide a link?

Eh, I asked for a link to the drupal-pot files you are using. Ie. what version? Official package?

Exactly. A few points:

- Drupal 6 templates are differently organized as there are a few oddities to fix from Drupal 5 (eg. small files should be small, not merged into general.pot) and also better suited for file placement now.
- Translations done with localizations server are not expected to be ever committed to CVS. The plan with l10n_server onwards is that a central l10n_server instance becomes the central place for localization editing and CVS will not be used in any way for translations. Translation packages will be generated by l10n_server and made available for download. So keeping compatibility with some existing standard is not a goal here.

Probably someone will make a patch for export to one file ? It is very inconvenient to translate these files locally.

Potx and the localizations server use completely different database tables, so potx is not usable for exporting stuff from localization server.

2 Gábor Hojtsy: - No, it is necessary small feature, for export to one PO file. One file is more convenient for translating(locally), than a little small.
Thanks for your work :)

subscribe :-)

I really wish we go back to only ONE translation directory and not this cluttered set of files in a deep nested structure. If i must search all my subdirectories first - if there *might* be a .po file or not - i get stressed on every update... Updating translations is not user friendly with this many files and will end up in duplicated and outdated files in some "hidden" directories...

Change this behavior, please.

hass, this is how Drupal 6 uses translations. It allows you to *not* clutter up your database with translations for stuff (modules, themes) you are not going to use. Once the translations server and other support tools are in place, the .po files are only a means of data transportation, and not going to be used directly by translators. For Drupal 6, the minimum set of files is something like the set at http://cvs.drupal.org/viewvc.py/drupal/contributions/translations/drupal... (This has all .po files for one directory merged, as is the current behavior of potx-cli.php when generating core templates).

Also, it became impossible to import a complete translation with one PO file all at once with the growing set of translatable strings in core, as it takes more then what PHP is allowed to take runtime and memory wise on most hosts. So we needed to break up the files for this reason too.

Yep, but i'm not talking of one merged po file for core. I know we need to split this for timeout reasons and batch api. POTX is splitting per module / theme and end up with one file per module or theme and this is what i expect here, too. Not a split inside my small theme what ends up with 6 files that are totally cluttered in the directory structure.

If we end up with more then one po file in /translations or /po that might be ok, too.

But today this ends with the following and make me searching and searching and searching for files:

contrib\translation\po\template-abb-php.de.po
contrib\translation\po\template-inc.de.po
contrib\translation\po\template-subcol-php.de.po
contrib\translation\po\theme-settings-fixed-php.de.po
layouts\mytheme_3col_standard_fixed\po\theme-settings-php.de.po
po\general.de.po

...and i have much more directories in "layouts" folder. I don't know why this export only end with one layout folder here... might be the duplicate strings, but i'm not sure. However this is cluttered and users need to search on every theme update for files - in all directories.

I'm not sure if i understand your "transportation" comment above. Transportation from d.o to the user or d.o to the download package!? However - if the user is made to understand all this structure them self - i'm pretty sure we will get *many* complains about usability and how to install this files and so on and so on. I don't know the full plan about this PO file delivery... i can only remember what you said in past - "we are not sure if we deliver packages with or without translations". Please think about usability here. Nobody likes to download a language pack and a module - splitted in two packages. I see my filling mailbox... why, how, what... please not!

Well, it is not hard to merge small po files in the same folder to one bigger file before output. But it takes a bit more to identify folders where actual stuff exists, which you will enable. Ie. you don't have themes in the layouts folder to enable, so po files shuold not end up there, and they will not be imported by autolocale or Drupal 6. So we should actually concentrate on putting po files of a comprehensible number to folders, where autolocale and Drupal 6 will find and import them.

A related problem is where you put the general.po file. It need to be impoted with the base module/theme of a module/theme suite, so it needs to be put where the base module/theme translations are, but with an arbitrary contrib project, we don't know where is this. Actually, l10n_server's base module is l10n_community, who knows that? :) I started a thread on this in october, but got no usable outcome unfortunately: http://lists.drupal.org/archives/development/2007-10/msg00119.html

So I fully acknowledge there are flaws in how the export files are generated, but there is no immediate solutions, and going through more bad export formats probably does not help much, thus I am trying to get feedback and plan for a bigger overhaul possibly executable at once or at least in bigger steps.

Maybe we are able to give the project maintainer a choice? A global check box per project translation could be a workaround. But i don't know how to solve this for sub-projects without having a path and the intelligence of what folder is a sub-module folder... the "image" project is a good example about this... it have ~5 .pot's...

So what we need:

- merge currently separate po files in the same folder
- "bubble up" the po files to a folder where it will be imported when it is not in a folder below a project (ie. directory with .module, .theme or page.tpl.php file in Drupal 5, .info file in Drupal 6)
- move common PO file to base module subfolder, and all files bubbled up when they end up in the root, if the root is not a module folder

Should I provide examples instead? :)

For me it's enough to get a working l10_server with this problem fixed. :-)))

I am trying to have a discussion, so instead of me taking a few hours to spec and implement a solution, we know in advance if I would do wrong anyways. So try to understand the proposed solution, and speak up if it is not right or not understandable. That helps me not waste my time.

Or to put it differently: the better we understand the problem, the more comfortable I am (we are? :) to provide a solution, so the sooner you get a bugfix.

I'd really like to have only one file per module / theme as we have had in past. I have no real solution or good idea for your submodule problem described in the link...

CCK is not a module, it is a module suite. So to have one po file per module, we need to solve the submodule problem for the sake of supporting all module and theme suites properly.

On one side - I think we need the maintainers for this job... or we need a list of files per sub-module in the info file. I only don't know if they like to provide this... on the other side they could decide in l10_server if they want only one file or more. But then we need a configuration tool that allows to configure what should be inside and what is a base module string... however this will end with some administrative overhead and i'm not sure - if this is what we want.

I know you are one the fence about importing something not required, but i don't see the big problem about this regarding base and submodules. The biggest modules i have translated were CCK, Panels 2, Image and some other popular - and they have had around 200-450 strings. That's very rare and most modules have less then 50 to 100. I think it does not create much harm if we import one file and we get all base and submodule translations together added - nevertheless the submodules will be activated or not... i'm not sure if we find a perfect solution without a file list per .info/.module file and i think it is toooo late to implement this for D6.

Totally different idea could be - make people to put submodules in subdirectories with .info files and we are able to build one PO file per base module and one per submodule. But this need some changes in D6 CCK for e.g. :-). Aside "Image" is something that would work good in this way. But this would not solve the D5 export... so we need a one file export for sure and we can tell D6 developers to use subdirectories or they only get one translation file. Then it's a developers decision to make translation modular (per submodule / per subtheme) or not. I really wish to have an administrative choice for one file - however i'm using subdirectories in my themes or not. Simply subdirectories provide modular translations and not using this way - not. Not very different from the way POTX is working today.

I hope this gives some more ideas. I'd like the ideas in my last paragraph most.

I from Drupaler.ru, i have problem with translate drupal core, many peaple have this problem, please fix this bug...

At http://drupal.org/node/203207 meba reports that the install profile .po file was improperly named, and thus core did not find the language properly. I folded that one into this issue, as it is exactly about po file naming and placement in relation to the project at hand.

OK, just committing a feature update which includes the following:

- an export format to export all strings for the selected release of the selected project in one big .po file (good for testing and smaller contrib modules, does not compress the exported file!)
- an export format which allows exporting a flat .po file structure (which nearly matches the Drupal 6 strcuture, except http://drupal.org/node/209517 hopefully) this lets you export files which are directly committable to Drupal.org CVS :)
- refined .po(t) file placement in flat mode and Drupal 5 and Drupal 6 packaging using the Drupal 6 conventions (grouping strings from files in the same folder to one .po file)

Hopefully this is much more sane and matches the Drupal 6 practices well. Comments for those doing Drupal 5 translations with this module:

- it does not hurt to use the new file scheme in your Drupal 5 *core* translations, the packager merges the files anyway
- most contrib translations will be fine with the all-in-one export mode, so you should also be fine there

Let me know if there is any issue with the new export formats.

http://drupal.org/cvs?commit=96033