Help make decisions about Drupal 6 translation template standards! Just two questions!

We face two important decisions when going forward with Drupal 6 development, and these should be answered before Drupal 6 code is frozen (in one month), so the core would be ready to handle the formats desired. Drupal 6 is supposed to get autolocale functionality (no, not the module itself, but a highly polished version of it's functionality) included, having improved support for running multiple operations sequentially under tight conditions (like shared hosts). So what type of translations templates we use will impact how Drupal performs and functions. Help shape our bright future!

The role of autolocale functionality is to import only the translations required on a site, helping the site perform much better. Of course it also gets better for the users, because we can get these translations imported automatically, but the performance improvement is much nicer. So we need to segment the translation templates to only what a user would enable on a site. Now every string appearing in multiple files ends up in general.pot, as well as output from small source files (less then 10 strings). Any larger file will get it's own translation template. With Drupal 6, these files will be shipped in a directory structure which combined with Drupal will resemble placement of contrib module translations, every module having it's own translations under it's directory.

The first question is how segmented the templates should be. Should we stick to a template per module, so even smaller modules get their own templates, not folded into general.pot, or should we keep small modules in general.pot? Separation would be helpful performance-wise. Common string would still stay in general.pot. What about modules with multiple files, like node.module, or system.module, which gets most of the include files? Should we have mega-files with one template per module there, or smaller files? This also has an impact on how can we import those, how much resources it takes to import a bigger file.

And here comes the second question. Drupal core translation templates (as of Drupal 5.x) also contain .info file string in general.pot, because you need module descriptions displayed to users before they enable the module, and before the translation of the module is automatically loaded. There is no solution for this for contributed modules though. As far as I have heard, many translation teams favor a "one translation template file per contributed module" solution for their work, but that does not allow importing of .info string earlier (Note that we can parse all the .po files at once, and try to grab out the .info translations, but if you suddenly copy 3-4 modules into your sites/all/modules folder and go to the modules screen, you would either get a PHP timeout or a progress bar before the module screen shows up, which are both "funny" results, not what you expect, and you would get disappointed). That is basically the same problem which warranted the "invention" of .info files in Drupal at the first place. So we can follow suit. A possible idea is to have very small translation files for .info files, resulting in at least two translation templates per module to translate.

Note that the automatic translation import system will allow for any number of translation files per module, named such as node-module.hu.po and node-module.de.po, as well as content_types-inc.hu.po and content_types-inc.de.po all in the same directory under modules/node/po. It is not a usability problem that people need to import multiple files, because they will not need to import it themselfs, Drupal wlll do it automatically. Especially if you help in making these crucial decisions. No need to code or patch anything, just add your two cents here!