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

>> we could equally well keep the combined files in svn as the
>> canonical po-file
> once we add freeciv-ruledit domain (See patch #4243) to the mix, 
> it becomes clear that domains should be completely separate
Aha, I didn't realise you had plans beyond "core nations". That does change
things a bit :)

> 1) Have nation ruleset to say which domain it belongs to. [...]
Well, we do have that information in nation group/set membership (groups=...,
"Core"). It would be easy enough to add an optional property to the nation set
definition in nationlist.ruleset for a gettext domain for nations in that set,
which would provide the relevant information at runtime. And a cheesy regex
could be used to filter nation files into the two sets when building
(I'd like to avoid a solution that means committers have to add files to the
correct if possible, because that's unnecessarily

That said, of those two options, I'm more inclined towards option 2, the
run-time search.
I'm not too worried about the performance hit (the most frequently used
"nation" strings are the nation noun/adjective, I think).
However, in general, trying to use multiple domains in a single application
does go seem to against the grain of gettext's design -- Googling for
"multiple gettext domains" finds various unhappy stories.
One concrete thing that I can think of that could go wrong is if people have a
language path set (e.g., fr,es,en) -- this arrangement would prefer a
translation from the user's lesser-ranked language if it happened to be in the
domain we searched first.

And I'm still worried about the usability from translators' and developers'
point of view, so I think we will need an automatic procedure of some kind in
the workflow to reconcile overlapping strings in separate domains.

(Aside: re R_() in patch #4243, I wonder if it would be sufficient to filter
on which source file contains a string, rather than explicit markup? With the
munging I detail later to deal with overlaps, I think that might be good


>> 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" [...]
> 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.
However, it seems that "msgcat" treats multiple input po-files as peers, and
in case of conflict will produce a fuzzy msgstr with conflict markers for the
translator to sort out.
(We could spot the presence of such conflict markers and warn at merge time,
but the existing workflow where we tell translators how many fuzzies they have
after merge would suffice.)

> 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.
...given the above I think it's possible to create a workflow where no
translator changes can be lost in this way.


Attached is a picture elaborating my previous idea (in rather vague terms) for
separate runtime translation domains.
* Set notation is used for "union" and "relative complement".
* For concreteness, I've shown "gd" as an example of a translator who prefers
separate files (so that they can give extended nations lower priority or
ignore them), and "fi" as an example of a translator who prefers to translate
all strings in a single file (because e.g. their tooling makes working with
multiple files a pain) -- these aren't necessarily the real preferences of
these translators :)
* Translations will never be lost, but they may "migrate" to their "correct"
file if they come in in the "wrong" one (or the "right" one changes, say due
to addition of a leader name to a core nation). It is implied that everyone
must translate "core" somehow.
* As shown, this implies frequent msgmerge'ing against source files; actually
I'm vaguely hoping this can be avoided (because it's very slow), but it
depends on the answer to the next question, I think:

One thing that's deliberately vague on this picture is what files actually get
checked into svn. Allowing variant per-translator workflows complicates this.
* If translators' "unclean" files get checked into svn, then we have to allow
different translators to have different subsets of files checked in somehow.
The build system may need to learn each translator's preference, which it
would be nice to avoid; otherwise it'll need to glob whatever files are lying
around, which is generally bad for reproducible builds.
* If we want to have a consistent subset of files checked into svn (without
loss of generality, the combined "fi.po") then the "munge" step has to be
applied on every commit, including in the workflows of translators with direct
svn access; and if svn is their working file, they are forced to re-import the
result into their tool after every commit.


The picture shows each application getting its own single message catalog at
runtime, obviating the need for a run-time search path. However, that leaves
> Supporting multiple domains could evolve to a system where 
> high-profile rulesets and scenarios could have translations. unsupported -- for that you definitely need support for multiple domains
at runtime, so the message catalogs can be distributed separately.

However, a single mo-file is not an essential part of this proposal, it's just
made easy by it.


My proposal may be overly baroque; I'm still not entirely sure it's a good
idea myself; but I think we will want something like its "munge" step
somewhere in our workflow, every if only as an optional check off to the side.

(file #19163, file #19164)

Additional Item Attachment:

File name: 4190_translation_workflow.png  Size:102 KB
File name:  Size:5 KB


Reply to this item at:


  Message sent via/by Gna!

Freeciv-dev mailing list

Reply via email to