[Wesnoth-dev] Adding a #textdomain directive (was: Toward a modular Wesnoth)

[Guillaume Melquiond]

On Thu, 17 Feb 2005 19:25:39 +0100, Yann Dirson wrote:
> On Sun, Feb 13, 2005 at 01:25:31AM +0100, Guillaume Melquiond wrote:
> > There would be one gettext domain by package, but there wouldn't be
> > the textdomain stack currently implemented in Wesnoth anymore. Maybe
> > you didn't play the CVS version thursday and friday, but you would
> > have seen that adding one single textdomain tag to the editor theme
> > broke almost the entire translation of the game. I don't want to see
> > such side effects anymore.

[...]

> But thinking more about it, I am not sure it is possible to get rid of
> the textdomain stack.

[...]

> Just adding a textdomain tag for this [unit] would allow to get the
> standard translation.  OTOH, if the original message is changed, the
> copy loses its translation, even though it has not changed itself.

You have convinced me that we could still make use of a textdomain
stack. However I think the current one should be scrapped. And we
don't even have to wait for a modular wesnoth; hence this proposal.

The current situation is as follow. The WML files are first
preprocessed, and the to-be-translated strings go through without
being modified by the preprocessor. Then the WML parser will get them,
and it will do a new preprocessing on the rhs of the assignations.
This preprocessing will include translating and concatening strings.
In order to do the translations, the parser will look for textdomain=
lines. In a sense, they are not real WML lines. For example, they
don't apply to all the config strings of a block, but only to the
strings following them. And hence they can even leak to upper files
(the editor fiasco).

I think pushing this whole work in the parser was a mistake.
Translating and concatening should be the preprocessor work (and doing
macro arithmetic, Yann's post). So I suggest adding two preprocessor
directives: "#textdomain [domain]" and "#endtextdomain". Any
to-be-translated strings between the two of them would get translated
accordingly to the domain.

Important point: the domain will never leak to including files nor
included files. It's as if a new domain stack was created upon
preprocessing a file, and if there was an implicit "#textdomain
wesnoth" at the beginning of each file. It also means that there is no
need for "#endtextdomain"s at the end of the file. And later, once we
switch to the modular system, the implicit "wesnoth" would be changed
to an implicit package name, so as to directly accomodate with
per-package translations.

To strictly limit the number of changes in a first step, only the
translating would be moved to the preprocessor, not the concatening.
Any objection? Any problem I would have missed?

Regards,

Guillaume