On Wed, Mar 18, 2009 at 05:09:25PM +0100, Arfrever Frehtes Taifersar Arahesis wrote:
> 2009-03-18 16:25 Jens Seidel <jensseidel_at_users.sf.net> napisał(a):
> > On Wed, Mar 18, 2009 at 03:54:58PM +0100, Arfrever Frehtes Taifersar Arahesis wrote:
> >> 2009-03-18 10:55 Jens Seidel <jensseidel_at_users.sf.net> napisał(a):
> >> > Bring PO files in the release branch in sync with source (to match all
> >> > strings from source and not only the strings as present many years ago).
> >>
> >> pl.po before r36624 intentionally contained some strings present in the future.
> >
> > And these strings are not lost. They can still be found as special comments at
> > the bottom of the file and will be automatically reused once they occur
> > after syncing with the source via po-update. Right?
To be honest I wasn't thinking about the case I assumed here (that a
translator added manually some msgid/msgstr pairs for future use).
Nevertheless once the PO files are updated before the release this case
is also covered.
> I meant messages which were marked as fuzzy in r36624.
Hmh, so you worry that commit r36624 demonstrated that you forgot to update
some strings? The current status of the Polish translation is
$ LANG=C msgfmt -cv subversion/po/pl.po
1970 translated messages, 14 fuzzy translations, 1 untranslated message.
This is completely unrelated to my commit! Without r36624 it would maybe
tell that pl.po is fully translated but this would be wrong as only the old
strings are considered. 15 messages are untranslated independent of any
action from my side!
But you're right, it is indeed possible that syncing with the source code
could harm: If a string for which a translation exists is changed in the
source a following sync would mark this string fuzzy. If this change to
the source is reverted the message in the PO file would still be marked
fuzzy, even after the next sync as gettext doesn't know what English string
was translated. This *could* be fixed using the --previous option of
msgmerge as a PO file would consist of 3 parts for fuzzy messages:
* the translated text
* the corresponding English text which was translated (in a comment)
* the current (changed) English text
Once the old (commented) English text matchs again the current text
the fuzzy flag could be automatically removed. Never tested this, though.
If msgmerge doesn't deal with this case a wishlist error should be reported.
Is this what you worry about?
Again let me summarize: PO is a simple, special file format which is
self-explanatory. It doesn't depend on further knowledge about the source,
special project rules, ... but just separates translations from code
development. As such the PO file syntax should be respected (and extensions
in the PO format such as --previous should not be rejected as it happens
with the self written Python scripts) and supported. Subversion doesn't need
any special rules compared to other projects.
The ordinary workflow for translating should also work with Subversion and
this works best if the PO file are up-to-date and in sync with the code.
I worked in the past on hundreds of projects and gettext simplifies
translations a lot. So let's assume that all normal PO file operations
are valid and OK for Subversion as well. If not, please write bugreports
against gettext (and yes, gettext isn't perfect).
Jens
Received on 2009-03-18 19:04:15 CET