Re: Splitting gnome-games into domains
- From: Christian Rose <menthos gnome org>
- To: Callum McKenzie <callum physics otago ac nz>
- Cc: gnome-i18n gnome org
- Subject: Re: Splitting gnome-games into domains
- Date: Tue, 09 Aug 2005 18:52:56 +0200
mån 2005-08-08 klockan 23:17 +1200 skrev Callum McKenzie:
> It has been suggested to me (bug #312802) that gnome-games should use
> multiple translation domains rather than the single one it currently uses.
> This seems to be a perfectly reasonable request since each of the programs
> is essentially separate and there are obviously currently some problems
> with different games using the same words to mean different things. It
> also seems to be fairly straight-forward for me to do as a programmer.
> However, I have some questions:
> a) Timing: I assume that this is going to be disruptive enough for
> translators that it should wait until the beginning of the 2.13/2.14
> b) The effect on translators: I don't really know how you guys do things.
> Is this going to be a major change from the translators perspective?
> c) Examples: Does anyone know, off the top of their head, of another
> package that uses multiple domains that I could use as an example? (I
> haven't looked hard yet.)
> d) Any objections to doing it at all? As I said: it *seems* reasonable to
> me, but I'm not an expert on this sort of thing. Note that it is also a
> lot of domains: one for each game and another for the shared library.
I'm generally *against* splitting modules into several translation
Typical reasons¹ include:
1. More often than not, whenever someone suggests "split this module
into several translation domains", it's evidence that the module needs a
splitup into several modules, for other unrelated maintenance reasons,
and so splitting the module up into several modules, instead of into
several gettext domains, is the better solution in the long term.
2. Often the reasons cited for splitting a module into several domains
is that there are context problems with some messages. However, those
problems should be solved by applying context markers where necessary.
3. If it's not reportedly broken, don't fix it. If noone has cared to
report a potential context problem with some messages, don't assume that
there is a problem. Don't do anything based on assumptions. Only the
messages that are actually causing problems should be fixed. See 2).
4. Splitting a single module into multiple gettext domains means that
translators will have to do duplicate work for all the messages that are
common or similar.
5. Translators generally expect modules to have a single po directory
where translations should be put. If you break that pattern by
introducing multiple po-* directories, then you can be fairly confident
that not all translators will notice all those directories where po
files have to be put, and consequently, you will end up with build
breakages because translators added their language to ALL_LINGUAS but
failed to put a corresponding po file in all the module's po
] [Thread Prev