As to replacing the files with the drupal 6 files. There's nothing preventing us from creating a two step scenario here, one would alter the table and set the flags on the initial drupal 5 installation, thus using the existing PO files (if any!). The other update would continue the processing (if needed) when the new drupal 6 files are in place.
<br><br>So then the process would go like this:<br><br>1. Every string MATCHING an existing string in a PO file would be set to "not modified"<br>2. Every string NOT MATCHING an existing string in a PO file would be set to "modified"
<br>3. Every string that doesn't exist in a PO file would be set to "modified"<br><br>Actually, this really makes sense, the user who's upgrading will most likely be content with the translations as they appear on his drupal 5 site, so it would be most reasonable to set a non-matching/non-existant string as modified to avoid overwriting it in future PO file dumps.
<br><br>By the way, how does drupal currently distinguish PO imported strings from web-modified strings? Or does it just overwrite everything on a PO dump?<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;">Ashraf Amayreh wrote:
<br>> hmm... we would know of any web modified values if we could<br>> theoretically gather all the PO files that were used on a drupal 5<br>> installation, right? I know little info about PO files so apologies if
<br>> I'm making any wrong assumptions here. I've seen PO files distributed in<br>> modules which would make this work, but I don't know how applicable this<br>> is if an external PO file was used or so forth. Any ideas on
<br>> applicability of this?<br><br>When you update from Drupal 5 to Drupal 6, you throw away your Drupal 5<br>code and you get the new Drupal 6 code. We will try to educate people to<br>grab the core language pack too before the upgrade. The problem is that
<br>we don't have the PO files used on the Drupal 5 site, if any... Many<br>people translate modules they have no translation for on the web<br>interface, because 'it is there'.<br><br>> In worst case, doing this technique on existing PO files is still better
<br>> as it will recognize some strings as "not modified" rather than either<br>> considering all strings as "modified" or "not modified". It's still<br>> better to use what PO files exist to get the least error margine I guess.
<br><br>If only we would have the PO files used before. With most Drupal 5<br>sites, the PO files are not in the webroot, because it was told to<br>people to import translations by uploading a big PO file. So they have<br>
the data in the DB but not likely that they have the exact source PO file.<br><br>> Also, what if the modified int (not bit) had a third "unknown" value,<br>> where the user could go and resolve these words? I'm really just
<br>> babbling some random thoughts here.<br><br>Hm, maybe we could do that for this interim period. Question is what UI<br>can help users here. It should be simple and quick. (We can have a few<br>languages with two dozen modules easily, which could result in many
<br>"unknown state" translations).<br><br>Gabor<br></blockquote></div><br>