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.
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?
On 5/22/07,
Gabor Hojtsy <gabor@hojtsy.hu> wrote:Ashraf Amayreh wrote:
> hmm... we would know of any web modified values if we could
> theoretically gather all the PO files that were used on a drupal 5
> installation, right? I know little info about PO files so apologies if
> I'm making any wrong assumptions here. I've seen PO files distributed in
> modules which would make this work, but I don't know how applicable this
> is if an external PO file was used or so forth. Any ideas on
> applicability of this?
When you update from Drupal 5 to Drupal 6, you throw away your Drupal 5
code and you get the new Drupal 6 code. We will try to educate people to
grab the core language pack too before the upgrade. The problem is that
we don't have the PO files used on the Drupal 5 site, if any... Many
people translate modules they have no translation for on the web
interface, because 'it is there'.
> In worst case, doing this technique on existing PO files is still better
> as it will recognize some strings as "not modified" rather than either
> considering all strings as "modified" or "not modified". It's still
> better to use what PO files exist to get the least error margine I guess.
If only we would have the PO files used before. With most Drupal 5
sites, the PO files are not in the webroot, because it was told to
people to import translations by uploading a big PO file. So they have
the data in the DB but not likely that they have the exact source PO file.
> Also, what if the modified int (not bit) had a third "unknown" value,
> where the user could go and resolve these words? I'm really just
> babbling some random thoughts here.
Hm, maybe we could do that for this interim period. Question is what UI
can help users here. It should be simple and quick. (We can have a few
languages with two dozen modules easily, which could result in many
"unknown state" translations).
Gabor