[development] updating translations: how valuable is user data after all?
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
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