|
From: Malcolm T. <ma...@co...> - 2002-09-06 05:51:05
|
On Mon, Aug 26, 2002 at 11:12:37AM +1000, Malcolm Tredinnick wrote:
[...]
> The current behaviour when I run
>
> scrollkeeper-get-cl sv scrollkeeper_cl.xml
>
> if to look in my LANG environment variable and run through all of the
> possibilities there. If any of them match the requested locale ('sv'),
> then return the 'sv' version of the contents file. If not, as a final
> fallback, return the 'C' version of the file. The upshot of this is
> that. although I have a Swedish translation on my box, I will always get
> the C version since, by default, my LANG variable is set to "en_AU".
>
> Why is this the algorithm that is being used? It should not care what my
> current locale is if I specify something on the command line.
>
> It's a fairly simple change to make scrollkeeper-get-cl just cycle
> through the passed in locale and its variants and return the first one
> that matches. By "cycle through", I mean that running
>
> scrollkeeper-get-cl sv_SE.ISO8859-1 scrollkeeper_cl.xml
>
> will check (in order) sv_SE.ISO8859-1, sv_SE, sv.ISO8859-1 and sv. As a
> final fallback, if none of those possibilities work, we could _then_
> consider what is in LANG and finally fall back to C as a last resort.
>
> (Note that by "fairly simple", I mean "I have a tested patch that does
> exactly what I described". :-) )
>
> In terms of functionality, this should not break anybody's setup, since
> the only thing they will see is possibly a localised contents list that
> they asked for, rather than the C version they got because LANG was set
> differently to what scrollkeeper thought it should be -- so things will
> work better than before.
Did anybody have any comments about this proposed change -- either
postive or negative? I'm tempted to just check in the new behaviour,
since it does not appear to make things behave any worse than previously
and it behaves better in some cases. However, I would like to hear at
least some murmers of approvement.
Malcolm
|