Abdelrazak Younes <[EMAIL PROTECTED]> writes: > > Charpentier Philippe wrote: > > My problem is not the encoding of the layout. It is that, since 1.2 > > version of lyx I used layouts I wrote and they contain definition of > > styles with non ASCII characters like this: > > > > Style Théorème ... > > > > Style Énumère ... > > > > Style Liste_à_puce ... > > > > etc... > > > > and I did it because these names appear in the GUI (and it was not > > written in the documentation that those name must contain only > > ASCII). > > > > This was working perfectly until 1.4.x. But now the 1.5 version crash > > if I want to use one of my layouts (independently of the encoding): > > non ASCII characters seems forbidden now for the Style name. As these > > names appear in the layout and in the documents, I am afraid that, if > > nothing is done for this I will never be able to use the next > > versions of lyx > > AFAIU, the problem is that the translation machinery requires that these > field are 7 bits ASCII.
The point there is that these are collected by the gettext mechanism (see for instance the IEEEtran template: the style menu offers the translated version of Theorem, Itemize and Enumerate as Théorème, LstePuces and Énumération). These known translations are uses by new layouts as far as the same style names are used. The layouts are parsed to build .pot field used for translations. The problem is that for new local style names, the user should update the pot file, merge with the current po file, edit the result, build the new format and replace the old one in the LC_MESSAGES directory. > 1) provide a python script that converts the layout as good as possible: > Théorème -> Theoreme > Liste_à_puce -> Liste_a_puce > > The problem is that it could be done easily for French but maybe not for > other languages. Second problem is that I am not sure we have a lyx2lyx > equivalent for layoouts, do we? > > 2) Accept the layout field as is and do not try to translate them. Given the burden of gettext management, this would clearly be better, but what about encoding ? From 1.5, the reference encoding is Unicode, so that style naming should be in Unicode in the layout file, and converted to the locale to display, like any other menu. Maybe some script to ease gettext management would be better, to keep this in the global translation flow. -- Jean-Pierre