Hyperion Entertainment Message Boards

In Locale prefs there is a list of "preferred languages". The top language is the one which should be selected first is available, then the next, etc.

However, WB and several other apps seem to be selecting the last entry in the list as the language to use.

eg. set preferred languages to:
english-british_ISO-8859-15
english
german

This always used to work under OS3 and for a time under OS4, but now WB, NotePad, the Shell, USB Inspector, UnArc etc all show up in German, as does FileX. TurboCalc is in English as expected (I have very few 3rd party apps with a German catalog installed to test)

Have the rules changed for the order of the preferred languages? The Workbench 3.0 (yeah, I know) manual clearly states:

Select the languages in order of preference from most preferred to least preferred. [...] If the application cannot provide the most preferred language, if goes down the list until it finds a language it can provide.

This quite clearly is not being followed with the list I'm trying to use (above).

The rules have definitely not changed, neither deliberately nor (judging by my experience here) involuntarily.

I have the following selected:
danish
english

And I do get Danish everywhere where Danish catalogs exist, including Workbench.

I'll see if I can recreate your problem with your specific selections (I'll try tomorrow).

Best regards,

Niels

Chris:

The "British-english" repertoire is pretty limited (let's face it, most of the devs speak American). It rankles but that's the way it is.

What happens if you leave out the "British-english" line and just have "english, german" ?

Right, I can confirm this.

I think it is - as Tony mentioned - a question of the english-british catalogs missing for most components (e.g. Workbench), combined with a bug (or less than optimal behaviour) in Locale, in that since english is defined as the default, built-in language in AmigaOS, it somehow skips that when present in the list of preferred languages, and only falls back to it once all other selected languages have been tried and found not to have the requested catalog available. Locale will always use english as a last resort in such a case, whether it was selected as a preferred language or not.

A workaround may be to have an english (not british-english, but "just" english) catalog for each of the components having the problem, even if such a catalog just contains one or a few strings. Having a catalog on disk matching the name "english" apparently should make Locale load it when it gets down to english in the list, instead of skipping english and moving on to (in the above example) german.

If I understood it correctly.

But it also requires an effort from the developer in the form of some special options that have to be used when opening the catalog in the program (it's discussed in the documentation in the SDK, apparently). I think most OS4 components should do this correctly by now.

Best regards,

Niels

Niels

I'm glad you could reproduce this. I just tried Tony's suggestion of only "english, german" and everything still comes up in German. I then tried the non-Euro version of English and everything works as it should. So maybe it is a character set problem? Locale is not recognising built-in strings as being English because they are in US-ASCII and I've selected ISO-8859-15?

If this is the case and your workaround of having a catalog on disk works (which isn't really practical for obvious reasons), then Locale's built-in language comparison against preferred langauges needs fixing.

Chris

Hmm, that fault rings a bell from way back. I seem to recall a discussion along those lines.

Niels?

tonyw wrote:Hmm, that fault rings a bell from way back. I seem to recall a discussion along those lines.

This sounds a lot like a problem which was fixed in locale.library a long time ago. The next update will include the updated locale.library.

@ssolie

Excellent, thanks.

The current public locale.library is pretty old (v53.3 (19/07/2009) - I guess not been in any updates since release) so doesn't surprise me if it has been fixed already.

@tonyw

I did report it somewhere ages ago but don't remember the outcome.

Ah, yes, I remember now (bug 4689).

In fact, I didn't realize Update 3 didn't have the same locale.library as our betas, so I just tested this on my clean Update 3 partition - and got the same results as chris .

I'll re-check the same test case ASAP with the fixed locale.library just in case.

Best regards,

Niels

This bug still exists in locale.library 53.4 (12/05/2010)

WB, NotePad, the Shell, USB Inspector, UnArc etc all show up in German, as does FileX.

WB, NotePad, UnArc and USB Inspector are all OK now, but the Shell, AmiUpdate, PrefsObjectEditor and FileX are (still) broken.