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
1- I think we could take as example some Linux distros. So the questions would go as...
a- Choose your default installation language - (Or it could be some icon or logo defining "speaking" with "?") Bases on the .po found.
b-(Now in the default language) - Choose all language that you want installed : That would be all .po files found with a checkmark if they want to install it.
2- Sounds good.
4 and 5 - Could a rollback or history versoning could be interesting? Subversion style? (but a lot of work I guess).
When the user would make an update, of the language pack or of a module, the system would ask : - There are some changes in the language file. Would you like to apply the changed? (All changes are kept, so you can come back) [Apply all changes check]-[no changes]
[check?] change 1 BEFORE1 AFTER1 ... [check?] change 2 BEFORE2 AFTER2 ... ...
And if someone would go in the locale module, and search for the BEFORE1 string, they could found all versions.
These are just idears ;)
On 9/2/06, Gabor Hojtsy gabor@hojtsy.hu wrote:
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 _______________________________________________ translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations
-
Alexandre Racine -
Gabor Hojtsy