"Asger K. Alstrup Nielsen" <[EMAIL PROTECTED]> writes:

| > Using gettext would be just a shorterm fix, and it would only be
| > correct when the locale lang is equal to the doc lang.
| 
| ...and therefore, we can't expect that we will have that in the shortterm.
| So, I think we should include the shortterm fix until we have the
| long term solution.
| 
| > The Right Solution would to have a gettext that was written for C++'s
| > locale support (able to use several locales at once), but until we
| > have that we can either:
| > 
| > - muddle on with gettext
| 
| This is the least intrusive solution, and thus the safest one.
| 
| > - have a lang file for each layout.
| 
| Are the "Chapter" strings in the layout files?  I thought they were
| hard coded...

Defined in the layout files.

However it seems to me that the _real_ correct solution is to use the
strings that babel provides. This should not be too difficult...what
would be required:

1. use variables in layout files and have hardcoded values for these
   variables¹ in lyx. Layout files should also be able to declare/defines
   the variables that is uses.
2. a mapping from variable name to variable contents inside lyx. this
   would be a map<string,string> There would be one such map for each
   document/language. It needs to be per document since different
   documents in the same language does not need to use the same terms.
3. means to extract the needed informatin from the babel .ldf files.
   This not be too hard and using the substring and the regex class
   form the old 1.1.x series should help a lot.

This would actually be a quite nice project. And does not require a
lot of internal LyX knowledge. 

        Lgb

¹ + Hardcoded in some data file most likely + the hardcoded values
    could be gettextified. 

Reply via email to