Follow-up Comment #4, patch #4190 (project freeciv):

> so if "Speaker %s" is translated in one but not the other it'll
> end up in both (and conflicts will hopefully be spotted).

Unfortunately msgmerge does not know "common ancestor", so it can't tell which
one of the two translations has changed (relative to ancestor), or if both
have changed. One of the files is always the primary one and the other is just
used to fill those translations that are completely missing from the other.

> we could equally well keep the combined files in svn as the
> canonical po-files (there's no technical need for separate
> catalogues to end up in binary packages, after all), and do
> the splitting at the translator interface: offer split
> po-files at, post stats on split files, etc.

Main benefit I see with this is that we wouldn't need to worry in the code
about getting translations from correct domain if we had only one.
One problem is that due to above mentioned msgmerge limitation there's risk of
losing translation changes when merging translator provided split files to
master. Converting the other way there's no such risk. If translator provides
translation in full po, all split files generated from it would get current
Supporting multiple domains could evolve to a system where high-profile
rulesets and scenarios could have translations.

> (The notion of splitting would still need to be reflected in
> our automake infrastructure to some extent

We would need both the master po-files, and split files automatically
generated from it. If we need split files to be ganerated only at 'make dist'
time this might be doable - we certainly don't want to add their generation to
time of 'make' or even 'make install'.


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to