How about leaving this has options? Overwrite or not in the website settings or in the local module...?<br><br>Or... asking the administrator what should be best on one page?<br>Like...<br><br>string1 that you have [ ] - string2 witch is new [ ]
<br><br><br><br><br><br><div><span class="gmail_quote">On 5/22/07, <b class="gmail_sendername">Gabor Hojtsy</b> <<a href="mailto:gabor@hojtsy.hu">gabor@hojtsy.hu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi guys,<br><br>Now Drupal 6.x-dev includes cool features to import PO files<br>automatically at every logical step:<br><br> - you can install Drupal in your foreign language, and have<br> PO files for all enabled modules imported along automatically
<br><br> - when you add a new language, all translation files for<br> enabled modules get imported automatically for that language<br><br> - when you install new modules or enable themes, the translation<br> files for these components get imported for all enabled
<br> languages<br><br>This is all great and automated, contrib modules already have their PO<br>files at the right place, and we will update the packaging scripts for<br>Drupal 6 to package core translations properly.<br>
<br>You might notice a pattern in the above features though: they IMPORT<br>stuff into the database. Unfortunately we have no way in Drupal 6 to<br>remove translations when you disable a theme or uninstall a module. We<br>
don't know what strings appeared in *only* that component, and not<br>elsewhere in Drupal, so we can remove them without problems. For that,<br>we would need the extractor script built into Drupal core to look<br>through all source files of enabled components and identify the unused
<br>strings in the database. Fortunately this is doable in contrib, now that<br>extractor has it's own Drupal module. (Of course it is doable in Drupal<br>core my deleting all strings from the database and reimporting files for
<br>only the enabled components, but read on about the value of user data).<br><br>BTW Drupal 6 core still need upgrade support for translations. So when<br>you update a module or Drupal itself, new and corrected translations get
<br>into your database. New translations are easy again, they are just<br>importing new stuff, which we are very good at :) Updating translations<br>already in the DB threatens user data though. In Drupal 5 and before, we
<br>have no information about what translations a user modified on the web<br>interface, so we don't know what was imported from available PO files<br>and what was user defined. We can reimport stuff from the files, but can
<br>easily loose/overwrite user defined/updated strings.<br><br>What can we do about not to loose user defined strings? We can easily<br>introduce a 'modified' bit into the locale translations (target) table,<br>just as it was in menu module in Drupal 5. That would help us from
<br>Drupal 6 onward, but it does not help us loosing user defined strings<br>when a Drupal 5 to Drupal 6 upgrade happens. So how cautious should we<br>be there?<br><br> 1. Do not overwrite any existing translation, risking that we leave
<br> incorrect and fixed translations in the database.<br><br> 2. Do overwrite existing translations on an update, risking that<br> we overwrite user modified translations.<br><br>Note that an update will not *remove* anything from the DB because we
<br>don't know what we can remove as explained above. It can *overwrite*<br>stuff though, and problems are around these overwrites.<br><br>So how should the update paths work for Drupal and for modules/themes?<br><br>
Gabor<br>_______________________________________________<br>translations mailing list<br><a href="mailto:translations@drupal.org">translations@drupal.org</a><br><a href="http://lists.drupal.org/mailman/listinfo/translations">
http://lists.drupal.org/mailman/listinfo/translations</a><br></blockquote></div><br><br clear="all"><br>-- <br>Alexandre Racine<br><a href="http://www.salsamontreal.com">www.salsamontreal.com</a> - La référence Salsa!<br>
<a href="http://www.alexandreracine.com">www.alexandreracine.com</a> - Site perso.