[development] updating translations: how valuable is user data after all?

[Gabor Hojtsy]

Ashraf Amayreh wrote:
> 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.

Well, how many of your Drupal 5 sites you have PO files handy? Even if 
you have, one of the reasons of introducing split (smaller) PO files in 
Drupal 6 is that we cannot read and parse a big PO file all at once if 
we are running under tight server resources (like a busy server with a 
default PHP time limit).

> So then the process would go like this:
> 
> 1. Every string MATCHING an existing string in a PO file would be set to 
> "not modified"
> 2. Every string NOT MATCHING an existing string in a PO file would be 
> set to "modified"
> 3. Every string that doesn't exist in a PO file would be set to "modified"
> 
> 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.
> 
> 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?

There is nothing to distinguish them, this is our upgrade problem, and 
will be our upgrade problem if we don't do something against it.

Gabor