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

[Ashraf Amayreh]

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 at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070523/c49461ea/attachment.htm