switching to en as the default locale

[Jeff Schering]

On 1/30/06, Matthew East <mdke at ubuntu.com> wrote:
>
> > Are you sure scrollkeeper supports "en" like it should?
>
> The following conversation might help:
>
>  [09:42:18] < mdke> hello all. the english language ubuntu documentation is currently installed at -C, I've just been trying to move
>           it to -en, but scrollkeeper doesn't seem to want to know. Can this be done?
>  [09:43:55] <@shaunm> scrollkeeper is usually pretty dumb
>  [09:44:03] < mdke> it likes C?
>  [09:44:14] <@shaunm> the thing with scrollkeeper is, if it doesn't have a translation for the language, it refuses to show any
>           documents in that language
>  [09:44:25] <@shaunm> and as far as it knows, it doesn't have a translation for en
>  [09:45:05] <@shaunm> so if you want to do it for ubuntu, what you'll have to do is make a dummy translation for en
>  [09:48:30] < mdke> do your docs use C?
>  [09:54:04] <@shaunm> yeah, we always just use the C locale for the source english docs
>  [09:54:08] <@shaunm> it's just easier that way
>
> Given this, I think it may not be worth abandoning the C locale. Thoughts?
>

It sounds to me like there's a bug in scrollkeeper. The proper
workaround is to provide a translation for en. C is not a locale for
documents.

We are dependent on tools such as xsltproc. Luckily, when xsltproc
sees a locale that does not exist (such as C), it uses en. We have no
guarantee that the developers of xsltproc will keep this feature We
are tied to a document processing tool chain that currently does not
mind the type of breakage that we have..

We may also find that for one reason or another we may have to switch
to Apache xslt processing tools (or some other tool chain), and not be
able to make the switch because those tools might not be as forgiving
as xsltproc when it comes to non-existing documentation locales.

I think we should provide a translation for en until scrollkeeper is fixed.

Cheers,
Jeff