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
