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
