On Thu, Feb 25, 2010 at 6:07 AM, Jürgen Spitzmüller <sp...@lyx.org> wrote:
>> OK, but adding a couple of lines of code makes this much nicer for
>> English users.
>
> But we do not only have English users.
Right, but English is the language I can test with confidence.
> I'm not even sure my current approach
> is suitable for all localizations. I think Japanese uses roman accelerators,
correct. It there a test to see if the characters are easy to enter? I
guess [a-zA-Z] is not sufficient, when I went to Europe I remember
that the keyboards had keys for common accented characters, I guess
you can type "ü" with a single keypress? In which case using
"to_ascii" and/or excluding characters not in [a-zA-Z] would not
always help.
> but the strings are non-roman (of course). I do not see how we can provide
> this with an automated approach.
In the worst case we could enumerate the options. Heck I'd even find
1: English
2: English (UK)
3: English (USA)
4: English (Canada)
More meaningful than
_English
E_nglish (UK)
En_glish (USA)
Eng_lish (Canada)
>> A couple of questions:
>> 1) Is using _("(") enough to make the code sufficiently multilingual?
>
> I doubt it. But you can try yourself. Just try different LANG environments.
Hmm, actually with the LyX-1.6 interface at least the _("(") seems overkill.
The French, German and Japanese translations all just use '('.
However I cannot internationalize the versions of LyX that I have
compiled myself, so I can't test trunk easily.
An approach which avoids using '(' would be to represent the languages
as a tree, and put the _ before the first available alpha-numeric
character in the string e.g.
{
{ "_English"
{ "(_Canada)"
{ "(U"
{"_K)" }
{"_SA)"}
}
}
{ "_French" }
}
resulting in:
_English
English (_Canada)
English (U_K)
Engish (U_SA)
_French
Would this approach be preferred?
--
John C. McCabe-Dansted
