Hi,
There is a small change in Drupal for 5.0.0, which enables you to provide translations for the installer. By providing a ja.po, it.po, de.po, hu.po etc for the default install profile (and copy the file into the default install profile folder), you can choose a foreign language in install time. (An installer.pot file will be available).
Now if you have any foreign language PO files for the installer, it assumes you are interested in the locale functionality and enables that module for you.
The question is how to process. The locale module should add some default languages into the database to start with.
#1: Should the available installer .po files define what languages are added by default? Ie. if I have de.po, it.po and hu.po files in the default profile folder, I would have German, Italian and Hungarian languages setup automatically during install time?
Once the language is set up, we should automatically import translations for enabled modules.
#2: How and when should we import translations? We might get away with enabling the locale module first strictly before any other module. Then if any other module is later enabled (system.module would be the second), we would look for .po files in the "po" subfolder of that module (just like these are placed in contrib modules) and import the .po files for enabled languages, if available.
#3: How should contrib modules handled? Should Drupal look for .po files in the po subfolder and import into the already set up languages? What to do with multimodule bundles, where you don't need to enable all modules (like links or ecommerce)? If you provide one .po file for the bundle, then you have many stuff to import, without a clear reason... Should we support payment-module.de.po type of filenames? Should we migrate to using these type of filenames only, so that simple de.po files will not work for standalone modules?
#4: How should updates get covered? Should the module import the new translations over the old ones? We have no information to clear translations from the database (no data to look for what translation corresponds to what module, and many translations are used in multiple modules). If we import new translations over the old ones, possible user customizations will get lost. If we only import new strings, updated (fixed) translations will not get into the DB. Should we tell the user to do database backups, and sidestepp this issue with overwriting all imported strings?
#5: There is an effort to support uninstallation. It is still a good question, how would that fit with locales. See questions #4 above.
I would very much value your opinions. I intend to submit a patch for Drupal as soon as possible, so we can get automatic PO import in 5.0.0. Unfortunately it is not possible to create a patch, if most of the above questions are still open.
Gabor