ResFinder

[Latin1] Only Western European languages, if I remember correctly. That said, and given we mostly speak English, French, German, Dutch around these parts, it isn’t an unreasonable suggestion because the alternative makes things really complicated.

I agree. I have made language list resources in Polish and Esperanto, which are not Latin1 encoded. I cannot see a simple way to display them correctly while in a UK Country/Territory. However, a change of Country does change the Alpahabet, so who knows how a Polish user might see things? ;-)

How have you implemented languages?

When you next get to a RO machine, download that LangSetup I linked to above. Read the application Help. It will save repeating it all here. If you do run on a RO4 machine, make sure that you have English as the language, otherwise you might get a Google Translate version, which is probably unreadable. ;-)

Ideally this would be part of an updated TerritoryManager

I do not think so. A user’s language preferences can be disjoint from the Territory or even the Country settings. It is only historically that we have tied them together.

I have been looking at what Windows does for its Regional and Language settings. It ends up with a choice of Language, but suffixes some, such as English, with a range of regional variants, which then set many of the things that Territory deals with. As you might expect, there are then lots of ways to customise everything.

in the resources lookup, we’d probably want to stick to English naming

Yes, that is the way I have done it. The other likely option is to use those ISO 639 codes. I quite like that.

It is already messy enough with Country vs Territory, and Alphabet to liven things up…

Unless someone makes it simple to write and include new Territories, I think that route may be practically closed, despite all the discussion earlier. The !Territory app was a brave attempt, but not really what is wanted IMHO.

I think a user Language preference sits alongside the others reasonably easily, especially if UTF8 becomes common.

but, hey, I never liked the Toolbox’s implementation of internationalisation

After the discussion earlier, neither do I. I think it has to be possible to use the same Resources organisation as you can with other apps using ResFinder or Language$Path. Unfortunately, I am not the one to find out where the problem lies and fix it. ;-(

Hope you slept well. ;-)

I have been looking more at Toolbox_Initialise. The problem seems to be about the use of ‘$’ after a path variable when used as the Resource directory: you must have one for RO4; you must NOT have one for RO5.

So, I now implement one or the other depending on the system, which seems to work.

I have uploaded this version, with some tweaks and bug corrections to the same location:

http://kappa.me.uk/Miscellaneous/LangSetup.zip

I have been looking more at Toolbox_Initialise.

You know I’m a believer in libraries doing stuff so the application author doesn’t have to. Seems to be that the toolbox ought to be tweaked to be smart enough to find its own damn resources and stop whinging… ;-)

you must have one for RO4; you must NOT have one for RO5.

How does RISC OS 3.70 do it? [is RO4 the odd one out, or RO5?]

I was going to do some work on my USBMIDI module, but I just looked at the C source and my eyes glazed over. I think I’ll go make a cup of tea and go to bed and listen to some music instead. I’m feeling about 50%, which is infinite-percent better than two days ago. But, my concentration just isn’t there. ¹

So instead, I will throw the furry feline among the feathered friends and say it would be good to have a configuration for regional settings that looks like this:

Setting the country will set the language/keyboard to the common default, but this can, obviously, be overridden by the user. It would also permit reconciliation with “United Kingdom” and “Welsh”; it always seemed to me to be a cop-out to call Welsh a separate country when it isn’t really, it’s a separate language.
Ditto for complicated cases like Switzerland with French, German, Italian, Esperanto, and however many official languages that place actually has.
Notice that character set has been reduced to accepting the OS default or UTF-8. Though, we might want to keep this greyed out until UTF-8 works (!Edit with kana is… interesting!).
The location is “facultatif” (that’s the French word, can’t remember what that is in English). Basically it does not change anything, but software that is location aware can read it to see where the user is (for example, that BBC news ticker software could look for news for the specified country in preference to UK, that sort of thing…).
Time zone is tricky. Should it belong here with regional settings, or with time and date? Both are valid places, though I suspect leaving it in time and date is more logical. It’s just an example.

See the little “Advanced” button? This is for power users and difficult-cases (i.e. people like me who want to keep most of the UK settings, but customise to local methods) to tailor their options. A tabbed window, something like this:

Yes, it is based upon Windows XP.

The window might be a little bit unwieldy. I didn’t want to entirely rip off XP, but if nobody cares it might be easier to remove the options below the Positive symbol and replace with a selection box called Positive format that will open a selection menu that looks like this:

Ditto for negatives. That should make the window a little more compact. Depends if you want verbose or not. ;-)

I have left out international vs local currency distinction. In some places there is a difference – we use the symbol “¥” for Yen, the Japanese write it as “円”. I would imagine the same holds true for countries that do not use a Latin alphabet? Something to consider adding, perhaps, is the international acronym – JPY for 円, EUR for €, GBP for £…

Same sort of thing for number format and date/time format.

The irony here is that the Territory system supports quite a lot of this stuff, it just can’t be changed on-the-fly. Certainly, I believe that any future decisions regarding country/keyboard/language should be handled by the Territory system in preference to the old-style OS method (with a clear distinction drawn between “Territory” and “Language”); but this will require numerous changes to the Territory system. There seems to be a lot of things missing – for example I see a lot of code to convert a time to a nicely formatted string; but I don’t see any call to say “given this value (main part in R0, fraction in R1) convert it to a number” or “…convert it to a currency”.
Look at the filer. Anything you like. $.!Boot.Loader – go to Info and it gives the size as 50331648. Wouldn’t it be better if it could throw that to Territory and get “50,331,648” or “50 331 648” (etc) back?

Maybe closer to summertime, I might have a crack at rewriting the thing in C/assembler?
We’ll need to bash out an API that we’re all happy with beforehand, though. That’ll be the fun part. Perhaps step one is to create a dummy module and see how much stuff breaks so we have an idea of how widely used it is? But, as I said, there will need to be some fundamental changes to separate the idea of language from the idea of country. Then, we could replace the idea of plug-in modules with a file containing *Commands to configure the behaviour (though we’d still need prebuilt files with the character type tables).

Oh, and whoever it was that suggested replacing ResFind/ResFinder with a system variable called Obey$Path ? +1 to that. That, built directly into Obey, would make life a lot simpler.

Right. Tea’n’bed…

¹ Wait – this is different to normal how? ;-)

toolbox ought to be tweaked to be smart enough to find its own damn resources and stop whinging…

Well, it does have a perfectly good method for itself, which works without any hiccups. I think the problem with path variables and $ is a more fundamental difference than the Toolbox itself. If a TB app is going to have resources organised along the lines suggested here I think it is going to be the programmer that has to account for the differences between the OS versions. It is not much hassle.

How does RISC OS 3.70 do it? [is RO4 the odd one out, or RO5?]

Good question. I do not know. I do remember discussion around a similar topic many years back.

it would be good to have a configuration for regional settings that looks like this:

I looked at that, then:

Yes, it is based upon Windows XP.

Thought so. ;-)

I like what you have suggested, but I fear only a few parts of it can be implemented without some very deep changes, and that would break all sorts of backward compatibility.

The irony here is that the Territory system supports quite a lot of this stuff, it just can’t be changed on-the-fly.

The Territory system is what we have, and that has been built in since RO3, I think. We can change Country, Keyboard, Alphabet and TimeZone after booting with a configured Territory. We can implement a new concept of Language, but can we change any of the other factors? Genuine question, I have not gone through them to check.

Ben Avison has pointed out to me how Territory is being developed and the number of Territories already defined. The source is available, but not the modules themselves. It would be good if they were compiled, even if they were not includes in the daily. With the amount of memory we have these days we could easily afford to have a selection loaded. Even windows has to be asked to install its international resources before they are used.

with a clear distinction drawn between “Territory” and “Language”

I agree.

t gives the size as 50331648. Wouldn’t it be better if it could throw that to Territory and get “50,331,648” or “50 331 648” (etc) back?

OS_Convert SWIs, particularly OS_Convert_Variform, which I think uses Territory separators. Only RO 5.18+ though.

there will need to be some fundamental changes to separate the idea of language from the idea of country.

I think this can be implemented independently from Territory, but initialsing itself from it.

I confess my reliance on older information, but there are far more Territory names allocated than I realised. However, there is still the problem of multiple languages, for which there are only a handful of allocations, and nothing to allow for a user who wants resources in a language that is not that of the configured territory.

whoever it was that suggested replacing ResFind/ResFinder with a system variable called Obey$Path ? +1 to that.

That was me. I am not really sure about that. It uses a system name for a special language purpose. Unless there were very strong support for this as a failrly fundamental change I do not see it is wise.

The source is available, but not the modules themselves. It would be good if they were compiled, even if they were not includes in the daily.

Try looking under “Internationalisation” on the downloads page, it’s been there about a year, and includes instructions on how to roll a !Territory application plus prebuilt binaries of the territory modules in CVS.

Thanks for the pointer. I think I was told what I said above, but I could easily have misunderstood.

Nevertheless, the existence and location of that archive is not obvious. I had searched both the Wiki and site for “Territory” and “Internationalisation” without finding it. Even your instruction to “Try looking under “Internationalisation” on the downloads page” is not directly helpful, because that page has no mention of it. You have to follow “Essentials”, rather ignore the leading paragraph and scroll down 3 screensful to find it. ;-)

I think this might be linked to the ‘Make download page friendly for [new] old users’ topic. ;-)