Hi guys,
Now Drupal 6.x-dev includes cool features to import PO files automatically at every logical step:
- you can install Drupal in your foreign language, and have PO files for all enabled modules imported along automatically
- when you add a new language, all translation files for enabled modules get imported automatically for that language
- when you install new modules or enable themes, the translation files for these components get imported for all enabled languages
This is all great and automated, contrib modules already have their PO files at the right place, and we will update the packaging scripts for Drupal 6 to package core translations properly.
You might notice a pattern in the above features though: they IMPORT stuff into the database. Unfortunately we have no way in Drupal 6 to remove translations when you disable a theme or uninstall a module. We don't know what strings appeared in *only* that component, and not elsewhere in Drupal, so we can remove them without problems. For that, we would need the extractor script built into Drupal core to look through all source files of enabled components and identify the unused strings in the database. Fortunately this is doable in contrib, now that extractor has it's own Drupal module. (Of course it is doable in Drupal core my deleting all strings from the database and reimporting files for only the enabled components, but read on about the value of user data).
BTW Drupal 6 core still need upgrade support for translations. So when you update a module or Drupal itself, new and corrected translations get into your database. New translations are easy again, they are just importing new stuff, which we are very good at :) Updating translations already in the DB threatens user data though. In Drupal 5 and before, we have no information about what translations a user modified on the web interface, so we don't know what was imported from available PO files and what was user defined. We can reimport stuff from the files, but can easily loose/overwrite user defined/updated strings.
What can we do about not to loose user defined strings? We can easily introduce a 'modified' bit into the locale translations (target) table, just as it was in menu module in Drupal 5. That would help us from Drupal 6 onward, but it does not help us loosing user defined strings when a Drupal 5 to Drupal 6 upgrade happens. So how cautious should we be there?
1. Do not overwrite any existing translation, risking that we leave incorrect and fixed translations in the database.
2. Do overwrite existing translations on an update, risking that we overwrite user modified translations.
Note that an update will not *remove* anything from the DB because we don't know what we can remove as explained above. It can *overwrite* stuff though, and problems are around these overwrites.
So how should the update paths work for Drupal and for modules/themes?
Gabor
How about leaving this has options? Overwrite or not in the website settings or in the local module...?
Or... asking the administrator what should be best on one page? Like...
string1 that you have [ ] - string2 witch is new [ ]
On 5/22/07, Gabor Hojtsy gabor@hojtsy.hu wrote:
Hi guys,
Now Drupal 6.x-dev includes cool features to import PO files automatically at every logical step:
you can install Drupal in your foreign language, and have PO files for all enabled modules imported along automatically
when you add a new language, all translation files for enabled modules get imported automatically for that language
when you install new modules or enable themes, the translation files for these components get imported for all enabled languages
This is all great and automated, contrib modules already have their PO files at the right place, and we will update the packaging scripts for Drupal 6 to package core translations properly.
You might notice a pattern in the above features though: they IMPORT stuff into the database. Unfortunately we have no way in Drupal 6 to remove translations when you disable a theme or uninstall a module. We don't know what strings appeared in *only* that component, and not elsewhere in Drupal, so we can remove them without problems. For that, we would need the extractor script built into Drupal core to look through all source files of enabled components and identify the unused strings in the database. Fortunately this is doable in contrib, now that extractor has it's own Drupal module. (Of course it is doable in Drupal core my deleting all strings from the database and reimporting files for only the enabled components, but read on about the value of user data).
BTW Drupal 6 core still need upgrade support for translations. So when you update a module or Drupal itself, new and corrected translations get into your database. New translations are easy again, they are just importing new stuff, which we are very good at :) Updating translations already in the DB threatens user data though. In Drupal 5 and before, we have no information about what translations a user modified on the web interface, so we don't know what was imported from available PO files and what was user defined. We can reimport stuff from the files, but can easily loose/overwrite user defined/updated strings.
What can we do about not to loose user defined strings? We can easily introduce a 'modified' bit into the locale translations (target) table, just as it was in menu module in Drupal 5. That would help us from Drupal 6 onward, but it does not help us loosing user defined strings when a Drupal 5 to Drupal 6 upgrade happens. So how cautious should we be there?
- Do not overwrite any existing translation, risking that we leave
incorrect and fixed translations in the database.
- Do overwrite existing translations on an update, risking that
we overwrite user modified translations.
Note that an update will not *remove* anything from the DB because we don't know what we can remove as explained above. It can *overwrite* stuff though, and problems are around these overwrites.
So how should the update paths work for Drupal and for modules/themes?
Gabor _______________________________________________ translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations
Alexandre Racine wrote:
How about leaving this has options? Overwrite or not in the website settings or in the local module...?
Or... asking the administrator what should be best on one page? Like...
string1 that you have [ ] - string2 witch is new [ ]
Do you think this is viable if you have to import around 30-60 PO files in multiple successive HTTP requests? Where would we collect these changes? If a translation team updated tens of strings, who would read and click through them all?
Gabor
Gabor Hojtsy wrote:
Alexandre Racine wrote:
How about leaving this has options? Overwrite or not in the website settings or in the local module...?
Or... asking the administrator what should be best on one page? Like...
string1 that you have [ ] - string2 witch is new [ ]
Do you think this is viable if you have to import around 30-60 PO files in multiple successive HTTP requests? Where would we collect these changes? If a translation team updated tens of strings, who would read and click through them all?
Add this in: you have three or more languages on the site, and you are the admin. Do you know all three languages to decide what translation is better for each case? Do you care to read through all the changes in all the languages? (It could even take hours).
Gabor
On 5/22/07, Gabor Hojtsy gabor@hojtsy.hu wrote:
Gabor Hojtsy wrote:
Alexandre Racine wrote:
How about leaving this has options? Overwrite or not in the website settings or in the local module...?
Or... asking the administrator what should be best on one page? Like...
string1 that you have [ ] - string2 witch is new [ ]
Do you think this is viable if you have to import around 30-60 PO files in multiple successive HTTP requests? Where would we collect these changes? If a translation team updated tens of strings, who would read and click through them all?
Add this in: you have three or more languages on the site, and you are the admin. Do you know all three languages to decide what translation is better for each case? Do you care to read through all the changes in all the languages? (It could even take hours).
Whatever the answer is, it is clear to me that the user should have the choice to have a default value. Either overwrite all the time or not. This should be an option in the locale module or something similar.
If everything is controlled by the website drupal.org, it would be interesting to have some kind of Rosetta (https://launchpad.net/rosetta) online to translate everything. I am not saying that Rosetta is perfect here, but online user-base-revision translations is the way to go if Drupal software just downloads everything from the website.
If a translation team updated tens of strings, who would read and click through them all?
Not one by one. In my idea, this would be more efficient on one page or 100 per page max. That might not be the best solution.
Gabor
translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations
Alexandre Racine wrote:
Whatever the answer is, it is clear to me that the user should have the choice to have a default value. Either overwrite all the time or not. This should be an option in the locale module or something similar.
Unfortunately we can't provide this option before the upgrade actually happens, because you cannot access the Drupal 6 site with a Drupal 5 codebase behind it.
If everything is controlled by the website drupal.org http://drupal.org, it would be interesting to have some kind of Rosetta (https://launchpad.net/rosetta ) online to translate everything. I am not saying that Rosetta is perfect here, but online user-base-revision translations is the way to go if Drupal software just downloads everything from the website.
*You* will download the packages, not the Drupal software. (Anyway, a web based translation interface is in the plans, but it has no connection whatsoever to Drupal 6 features).
Gabor
My vote is for override with a warning. Users who want to keep existing strings could export them and then re-import after the upgrade. Maybe even auto-export into a backup directory?
Tony A.A.
On 5/23/07, Gabor Hojtsy gabor@hojtsy.hu wrote:
Alexandre Racine wrote:
Whatever the answer is, it is clear to me that the user should have the choice to have a default value. Either overwrite all the time or not. This should be an option in the locale module or something similar.
Unfortunately we can't provide this option before the upgrade actually happens, because you cannot access the Drupal 6 site with a Drupal 5 codebase behind it.
If everything is controlled by the website drupal.org http://drupal.org, it would be interesting to have some kind of Rosetta (https://launchpad.net/rosetta ) online to translate everything. I am not saying that Rosetta is perfect here, but online user-base-revision translations is the way to go if Drupal software just downloads everything from the website.
*You* will download the packages, not the Drupal software. (Anyway, a web based translation interface is in the plans, but it has no connection whatsoever to Drupal 6 features).
Gabor _______________________________________________ translations mailing list translations@drupal.org http://lists.drupal.org/mailman/listinfo/translations
-
Alexandre Racine -
Gabor Hojtsy -
The Golden Condor !