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

[Ashraf Amayreh]

The only two options I see in this case is either to give them a status of
"unknown" or to somehow query the user for the behavior he wants during the
update (either to preserve them, modified bit set, or to make them
overridable, modified bit unset). How we can query a user during an update
is a mystery to me.

I would go for creating a third status of unknown as this will open up other
possibilities later on since they will at least be distinguishable from
normal strings. It will also by some time if the code freeze is "frozen".

What we could do with them after that is open to suggestions, but I can
think of a scenario where importing future PO files could check for their
presence and then setting their status to "modified"/"not modified"
according to weather they match the PO file strings or not. There's really
no totally clean way to solve this. Any assumptions on behalf of the user
could bear real bad consequences.



On 5/23/07, Gabor Hojtsy <gabor at hojtsy.hu> wrote:
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070523/b7c8b917/attachment.htm