Michael Gerz wrote:
Hello,
I guess I am not the only translator fighting with the innumerable
variants in the layout strings.
Me, too (although I almost completed work)
All the layout strings are currently marked as translatable, and it
is up to the translator to decide if he should try to adapt them or not.
But, as I understand it from the manuals, some of the layouts are
language-specific. Obvious examples are the English or German letter
layouts.
It could be "en" for all the scientific publications and English
letters, "de" for the German letters, and "all" for the multi-usage
layouts. Only the strings from the files tagged "all" would go into
the po file.
Yes, that would be a good idea. However, I think it would be better to
have a "translatable" flag only. From the point of view of a Spanish
guy, it does not really matter whether the document is English or
German as long as it is non-translatable. The flag should also be used
internally by LyX. Otherwise, LyX will translate some label strings
accidentally.
Jean-Marc,
I think we should do something in order to resolve this issue BEFORE
1.4.0 is released. It is a real nuissance for all translators.
What comes into my mind are two things:
1. In ./po/Makefile.in.in, we should consider a positive/negative list
for layout files that are (not) to be translated. Alternatively, we
could add a standardized comment in the header of each *.layout and
*.inc file.
2. In the layout definitions, there should be an option that allows
specifying a set of valid languages. This option should be exploited in
the document settings dialog.
Ideally, both (1) and (2) should be introduced. In a first step, we
could consider (1) only but then LyX might translate some label strings
accidentally if the user changes the document language (also
accidentically). IMHO option (1) alone is way better than the current
situation.
I am willing to spend some effort on the layout files but I would like
to get your opinion first.
Michael
PS: How about fixing/improving label strings? Are you willing to accept
corresponding patches at this stage?