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