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?

Reply via email to