>> I use for example in all my German
>> documents commands to translate the word "Index" to Stichwort- und
>> Befehlsverzeichnis" or similar. Therefore I have a a babel call in my
>> preamble in 1.5 documents.
>
> You don't need this babel call. You can use \AtBeginDocument, and it will work
> both with and without hyperref.
But why do we have the problem then? When people would have used \AtBeginDocument, they wouldn't had
a manual babel call in their preamble and thus we wouldn't have this discussion. To repeat my self,
we don't have any problem, except of people that loaded babel manually in the preamble.
>> With the current solution you only have to adapt your preamble once when
>> going from 1.5 to 1.6 but then can use 1.6 and all its features or not.
>> That's how it should work in my opinion.
>
> No. It is not acceptable that users who do not change their document do have
> to make a change in order to get them compiled.
But this has always been the case. I had to adapt my preambles for every new major LyX release in
the past.
> It is acceptable (albeit not desirable) that users who change their document
> anyway (i.e. switch on hyperref support) will have to adapt their document
> otherwise.
In this case it is acceptable?. This is inconsistent.
>> but also caption.
>
> Caption works for me in 1.5. I see no problem.
No it doesn't: you have to load babel before caption to be able to change the caption naming and
language settings. In LyX 1.5 you therefore have to load babel manually in the preamble, leading to
problems, as you need to adapt this call with every change of the languages used in the document. In
LyX 1.6 it works out of the box.
Therefore beeing forced to load babel manually in the preamble is often leading
to problems.
As said the changed babel loading position has been chosen because it has more advantages than
disadvantage, so why don't we able to use it then. I mean we cannot use a non-optimal loading
position forever just for the reason users might have defined something in their preamble. It is
still my opinion that when you modify the preamble, you know what you are doing, this is also
clearly stated in all documentation files since I use LyX.
>> I see your point, but loading bale after the user preamble was in general
>> not the correct place. You will run again and again into the situation that
>> babel needs to be loaded before packages that deal with words that need to
>> be translated. So the babel loading change was not only made only for
>> hyperref, but for general better support as you can of course only change
>> or define word translations and language issues after babel has been
>> loaded.
>
> If language translation is the issue, there is \AtBeginDocument. Any other
> problem?
Some packages behave differently when babel is loaded or not. Therefore packages require that babel
is loaded before. I heven't seen yet the opposite case.
> Also note that we changed the loading order because some packages need to be
> loaded _before_ babel. Cite.sty is a candidate.
I checked http://www.ctan.org/tex-archive/macros/latex/contrib/cite/ but can't find any hint about
this there. If the package author didn't say anything about babel and it makes problems, that the
package author should be informed to fix the babel support issues. I'm against building in hacks for
packages that are buggy (if this is the case).
> And this a crucial problem: If I have to insert a command or package that has
> to be loaded after babel, I can always do that (with \AtBeginDocument or with
> manual \usepackage{babel} in preamble). However, there's _nothing_ I can do
> in your the version if I have to load a package _before_ babel.
What exactly is such a case? I'm not yet aware of this. I once asked on TeX mailing lists with the
result that when a package cannot handle babel it is buggy or the package is no longer maintained.
There haven't been any bug reports about this since the change has made 9 months ago, so I need to
see first the case where a package really needs to be loaded before babel.
> >> Does anybody found a drawback instead of this?
>>
>> Has anybody?
>
> Loading a package before babel is not possible anymore.
When you present a case where this is really needed, I can and will agree with the solutions you
proposed.
regards Uwe
