On Thu, 11 Feb 1999, Jean-Marc Lasgouttes wrote:
> >>>>> "Joacim" == Joacim Persson <[EMAIL PROTECTED]> writes:
>
> Joacim> On Thu, 11 Feb 1999, Jean-Marc Lasgouttes wrote:
> >> Unfortunately, I do not have a good solution to this problem. This
> >> might change in 1.1.
>
> Joacim> ...? I just gave you the solution! ;) (for 1.0 series that is;
> Joacim> if 1.1 goes multilingual we'll have a different situation)
>
> It seems a bit complicated, though.
It *is* a complicated problem.
I gave it a second though on be bus home yesterday; forget the `family' file, it's
not necessary. Instead we can have one more lines for the
Style-definitions in the layout files; a named Category. ...it's allways
only a matter of comparing two layouts at the time, so the whole family
doesn't have to be gathered. Besides, this is easier to implement. ;)
Something like this:
######### book.layout
.
Input stdclass.inc # which Inputs stdsections.inc
.
.
Style Chapter #Overloading Chapter defined in stdsections.inc
Category Heading1 # Chapter is the top level heading in this layout
End
Style Section
Category Heading2
End
.
.
######
And:
##### article.layout
.
.
Input stdclass.inc
.
.
NoStyle Chapter
.
.
Style Section
Category Heading1 # Here, Section is top level heading
End
Style Subsection
Category Heading2
End
.
.
##########
Then when the layout goes from book to article, LyX looks for a Style from
article.layout in the same Category as Chapter in book.layout and uses
that instead of Chapter, likewise with book/Section -> Heading2 -> article/Subsection
...and a layout implementor doesn't have to touch a /global/ family file.
>
> Joacim> (here we go again ;): Don't mix up locale with document
> Joacim> language --
>
> *You* mix up locale with document language :) If I write an english
> document with a french locale, I expect to see 'Chapitre' instead of
> 'Chapter' in my toolbar. The .lyx file should contain 'Chapter' as
> layout name, however.
OK, I see your point ("Itemize" would have been a better example -- I think
it makes sense to have the same word in the env.list as is used for the label
string in the doc view. Itemize is just a name and has little to do with
the document.)
But don't use gettext for that or you'll be expected to release a new fr.po
each time someone adds a layout for some obscure LaTeX-class. ;)
There is also a risk of name clashes as gettext only have one entry for the
original strings; if the same name is used for two completely different
purposes in two different classes, well... po-files doesn't scale well.
[snip]
> I somewhat agree with that. However, I'm not sure that a layout file
> with multiple translations is the best solution. Maybe something like
> what KDE does:
>
> Style Chapter
> GUIName[fr] Chapitre
> GUIName[se] Whatever
> LatexName chapter
> [...]
> End
plus
LabelString[language] # i.e. strings for the document language
and probably, for classes from AMS and KOMA:
Preamble[language] # may need to set things up manually
since babel doesn't translate all the text strings in all classes, only the
LaTeX standard classes. ...a LatexName[language] may also be necessary.
I'm not sure how to handle multilingual docs in this case. I think it would be
easier (and safer) to specifically define a layout for bilingual (or
multilingual) document layouts (preamble may need some tweaking that can't
be done automatically).
We still need something for swapping layouts though. Some odd LaTeX class
may have environments wich in the accompannied layout-file has names that
doesn't exist in another class/layout, allthough the latter has something
that is roughly the same. The Category-method above could perhaps be even
better if we use a hierarchy as: "Category Numbered Lists" or
"Lists/Numbered" so that LyX can pick any list if a numbered list is not
available. (lousy example, but there may be cases similar to that)
Another thing about layout files I'm not quite happy with is the
NoStyle-statements. I think it would be clearer to define what
environments are available in a certain layout by listing them in the
layout file rathter than removing styles from a perhaps varying set.
If we put the locale- and doclang-specific strings in a base layout (or
inc's), we could bundle that with the Category-fication:
## book.layout:
.
Input stdclass.inc
.
Environments # declaration of environments in use
Category Heading1 Chapter # defined in stdsections.inc
Category Heading2 Section
.
.
End
.
.
######
...?
Joacim
-
With both feet on the ground, you won't get very far.
-- Loesje
