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

Gabor Hojtsy gabor at hojtsy.hu
Tue May 22 22:08:42 UTC 2007

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.


More information about the development mailing list