The only two options I see in this case is either to give them a status of "unknown" or to somehow query the user for the behavior he wants during the update (either to preserve them, modified bit set, or to make them overridable, modified bit unset). How we can query a user during an update is a mystery to me.
<br><br>I would go for creating a third status of unknown as this will open up other possibilities later on since they will at least be distinguishable from normal strings. It will also by some time if the code freeze is "frozen".
<br><br>What we could do with them after that is open to suggestions, but I can think of a scenario where importing future PO files could check for their presence and then setting their status to "modified"/"not modified" according to weather they match the PO file strings or not. There's really no totally clean way to solve this. Any assumptions on behalf of the user could bear real bad consequences.
<br><br><br><br><div><span class="gmail_quote">On 5/23/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>> As to replacing the files with the drupal 6 files. There's nothing<br>> preventing us from creating a two step scenario here, one would alter<br>> the table and set the flags on the initial drupal 5 installation, thus
<br>> using the existing PO files (if any!). The other update would continue<br>> the processing (if needed) when the new drupal 6 files are in place.<br><br>Well, how many of your Drupal 5 sites you have PO files handy? Even if
<br>you have, one of the reasons of introducing split (smaller) PO files in<br>Drupal 6 is that we cannot read and parse a big PO file all at once if<br>we are running under tight server resources (like a busy server with a
<br>default PHP time limit).<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<br>> "not modified"<br>> 2. Every string NOT MATCHING an existing string in a PO file would be
<br>> 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
<br>> likely be content with the translations as they appear on his drupal 5<br>> site, so it would be most reasonable to set a non-matching/non-existant<br>> 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<br>> from web-modified strings? Or does it just overwrite everything on a PO<br>> dump?<br><br>There is nothing to distinguish them, this is our upgrade problem, and
<br>will be our upgrade problem if we don't do something against it.<br><br>Gabor<br></blockquote></div><br>