Czech territory module

Hi folks,

I have a customer who routinely uses a Czech territory (despite living in UK). Not quite sure why that would be desireable (possibly access to characters?) as I have never really explored using other territories. So, two questions – is a RO5 czech territory available anywhere? I don’t see it in the list in BonusBin.

Second, given that it is unlikely to have a translation, and the user would be running in the UK with a UK keyboard, what would be the practical benefits of a czech territory?

Thanks,

Andrew

The territories I can see in the source tree are

- UK
- Master
- Compact
- Italy
- Spain
- France
- Germany
- Portugal
- Esperanto
- Greece
- Sweden
- Finland
- Denmark
- Norway
- Iceland
- Canada1
- Canada2
- Canada
- Turkey
- Arabic
- Ireland
- Hong Kong
- Russia
- Russia2
- Israel
- Mexico
- Latin America
- Australia
- Austria
- Belgium
- Japan
- Middle East
- Netherlands
- Switzerland
- Wales
- Maori
- USA
- Wales2

Not all of these have full support – probably all have keyboards and summertime settings (though if they are up to date I don’t know). UK, Germany and (to a very small extent) Swedish have some further localisation in terms of actual translations, but I haven’t tried that. No trace of Czech or even Czechoslovakian as far as I can tell.

Thanks Andreas.

The Czech one (from a quick google search) is probably by James Bursa – there’s a downloadable RISC OS 3 era one, but the source link is broken. Not sure if he’s contactable.

As someone who has never used a territory module, what are the benefits over just doing a *alphabet command, and/or setting keyboard (not applicable in this case), assuming that the user speaks English?

The only otherwise-insurmountable thing that I saw looking at the source (very, very quickly) was the ability to change sort order so that accented characters would appear at their correct position. I think this pre-supposes applications use RISC OS SWIs for sorting, of course.

There’s probably a lot more too it that I’m missing, plus the convenience of having all the changes in one place (not to be sniffed at).

I think I need a “crash course” on this part of RISC OS to get up to speed.

Territory seems to conflate language, keyboard layout, date-time formats, currencies, alphabets. I seem to recall Nemo posting at length about this.

Good luck. You need an answer to your first point – why is he doing this?

I think this pre-supposes applications use RISC OS SWIs for sorting, of course.

You get a bit for free in C – the SharedCLibrary does use the Territory SWIs these days to populate its isupper()/toupper() etc. tables and for strcoll() sorts.

what are the benefits

<rant>

On the face of it, Territory was supposed to be a good idea. By choosing a Territory, you get the keyboard layout and language set up, the timezone set up, plus some other things like the system understanding that Á is an upper case character while è is not. Along with this, some other stuff is thrown in, such as the currency symbol and the number formatting. Not that much use is made of this. The number “1,234.56” would possibly confuse a Frenchie at first, as they’re more used to seeing “1.234,56” or “1 234,56” (certainly, at work I had to learn to give numbers as something virgule something (virgule=comma)).

The problem is, the system is horrifically broken. All of these settings are hardwired into a module so the user cannot change anything without either creating a new module or hacking the one in memory in some manner. I had to bake my own module in order to have UK with the euro symbol and CET/CEST timezones. Because the standard setup just can’t handle expats. [actually, I’m running a fairly recent ROM so I don’t recall if my hacked UK module was a softload or built into my ROM, I’ll need to check]

Not only that, but there is a fairly direct assumption that a territory equals a language. I could point out Switzerland and it’s four official languages, but it’s just so much easier to point at Wales. Territory, as it stands, treats Wales as something distinct from the UK (well, maybe that’s what they’d like these days?). As if that wasn’t bad enough, there are two Welsh territories. No Scotland, for what it’s worth. :-) The fact that Territory is so broken for it’s own country of origin really should have been a clue as to “you’re doing this utterly wrongly”.

Additionally, a lot of software uses Territory assignations to pick the language that a program should be in (in the rare case where there are translations), reverting to UK (English) in the absence of an appropriate language set. Again, it fails. For Switzerland, French or German (etc etc) would be a better fallback than English. Austria → German. Belgium → French or Flemmish (which doesn’t appear to have been thought of). Three Canadas? A Maori but no New Zealand? All of Latin America (you do realise they don’t all speaka española bandida don’t you?). Since when has Esperanto been a place? It’s just so buggered up it.

I shall make no comment over the lunacy of “Arabic”, “Middle East”, and “Israel” except to point out that wars have been started over less.

So, Territory is supposed to offer a lot more than just “here’s an alphabet and here’s a keyboard layout”.

Maybe some day it’ll be capable of doing it correctly.

</rant>

Thanks Rick – that was more-or-less my takeaway from what I came across via searches.

In your case, what does your modified territory give you that issuing *configure keyboard and changing the time zone does not? Is it primarily the handling of accented characters? The Euro thing is an interesting one as I don’t think the OS does much currency related, does it? But presumably you’re use is mainly the ability to easily type a euro symbol on the keyboard?

I use the French terrytory module, I need it for !Organizer the dates are thus francized.
The French keyboard is chosen with !Configure, I could have continued with the UK territory and still have the French keyboard.
The other reason is for !SciCalc as Rick says, the French use the comma instead of the point for decimals.
It didn’t work, because there was a bug in the application’s RunImage. It now works with the version of Hardisc4 ROOL.
My version has an advantage that I can enter decimal numbers via the keypad, the point being interpreted as a comma by !SciCalc with the French territory module.
Returning to the UK territory the keypad point becomes again a point for SciCalc.
This possibility does not seem to exist in !FireWorks, for decimals and dates. The use of the module made by Organizer is good.

These are examples to illustrate the use of the Territory module.
It would be nice to have the OS French, this would attract portential users. It’s possible, but that’s another story.

Fireworkz can be configured to swap point and comma for numbers – change the SSContext command in the Config file to set up (as well as defining some new suitable number formats / changing existing ones):

{SSContext:.;,;.;:;\\\;;,;\\\;;\\\;;0}

these being the thousands char, decimal point char, date sep char, time sep char, array col sep, array row sep, list sep char, function arg sep, spreadsheet ui flag (leave this at zero as there are no translated spreadsheet function names in current copies).

Anything further please take to the Fireworkz Google Group.

It even almost has French and German versions with menus, dialogue boxes, spreadsheet function names…

Will… (I’m damned late, but still on this)

change the SSContext command in the Config file to set up

That’s something Territory is supposed to handle. ;-)

In your case, what does your modified territory give you that issuing *configure keyboard and changing the time zone does not?

Timezone by name. Also properly understanding the timezone offset and date of summer time change. Euro as currency. Comma and period switched in numbers.

Granted, the latter two options are barely used by software (note the above post, Fireworkz does it’s own thing).

Is it primarily the handling of accented characters?

No, it’s still 8859/1 so nothing different there.

It’s basically to have things set up “like France” without having random applications thinking they should be communicating with me in French.

It would be nice to have the OS French,

That would require a full Territory as opposed to a replacement module. Does the OS look for Territoires on harddisc these days? The last time I messed around with it (RiscPC era) it popped up a graphic of an enormous badly drawn floppy disc. Not even remotely subtle. :-)

For what it’s worth, living in NZ, the only thing I ‘miss’ from not having a territory is that the system can’t automatically enable/disable daylight saving. Aside from that I’m using the UK territory, have configured my keyboard and time zone through the UI, and I think I set my *Country to Australia to get the right Wi-Fi channels.

Of course, things would be a different story if I didn’t speak English!

The last time I messed around with it (RiscPC era) it popped up a graphic of an enormous badly drawn floppy disc.

It still did that circa OS 5.20, when I last played with it.

an enormous badly drawn floppy disc. Not even remotely subtle. :-)

Not subtle, I agree – and not really any clue what it means.
When I queried this a while ago, I was told that it was because at that point the system did not know the territory (because there had been some error) so the ‘prompt’ needed to be territory (ie language) independant – hence the graphic. So my offer to change it to (or add) meaningful text was declined. And if I saw it today I would have to find & consult my notes to see what to do! ISTR it was to indicate that a valid !Territory had to be provided on some storage medium?

Additionally, a lot of software uses Territory assignations to pick the language that a program should be in (in the rare case where there are translations), reverting to UK (English) in the absence of an appropriate language set.

How true is that, though (the “uses Territory assignations” bit, that is)?

Also, don’t assume that just because there are no translations, that an app won’t attempt to use them if they were to appear.

Again, it fails. For Switzerland, French or German (etc etc) would be a better fallback than English. Austria → German. Belgium → French or Flemmish (which doesn’t appear to have been thought of). Three Canadas? A Maori but no New Zealand? All of Latin America (you do realise they don’t all speaka española bandida don’t you?). Since when has Esperanto been a place? It’s just so buggered up it.

A lot of apps (at least non-Toolbox ones) seem to have given up on the Territory number for language (perhaps using it for stuff like decimal points, as CashBook does) in favour of the “ResFind approach”. Broadly, that’s done on Country number, with the wrinkles that <AppName$Language> and <ResConf$LanguagePref> can trump the configured country in that order, and <ResConf$LanguageSuff> can act as a fallback before “UK” is taken as a last resort. The two ResConf variables are lists, too, so most combinations can be worked out.

If you go looking, there’s a fair bit of stuff out there which uses ResFind – which probably just shows how broken the OS support is.

The setting of a configured territory that is not in ROM is covered in the PRM Territory chapter under “Loading and setting the current territory”. This is p3-787 originally, but is to be replaced completely by p5a-671.

The original tells you about the floppy disc icon, but the replacement does not. Curiouser and curiouser …

@Stuart
Thank you for this info.
I used to define a new number and currency format for each new file.
I also saw that in the config file, we could redefine the name of the months and days, etc in {NumformData …}

We must also be able to translate the text of the menus.

To test.

When this topic arose at least the time before last, in 2016, I wrote a !RegionRes resource and a Region plug-in for Configure. These are definitely alpha quality. ;-)

Although this arrangement goes a some way to dealing with the problems that come up here, time-and-again, it is probably not a proper solution.

However, there is quite a lot of documentation, explaining what it is doing, that is still relevant. I will not replicate that here, but I would very interested in comments if anyone can be bothered.

The plug-in uses Basalt, so I would not be amazed if some machines have trouble, but I have checked it over here and it works. If anyone looked at it before, there are some additions since 2016.

Region is at: http://www.kappa.me.uk/Miscellaneous/swRegion027.zip

Edit: I have realised that is a dump of all the development files. I will cull the excess. Meanwhile, the earlier much smaller, version is at: http://www.kappa.me.uk/Miscellaneous/swRegion026.zip

This is p3-787 originally, but is to be replaced completely by p5a-671.

Or 3-795 and 5a-679 if you’re reading the PDFs that come with the DDE.

Meanwhile, I’ve noticed what appears to be a bug in the GitLab viewer. The UK territory contains Currency SETS "" with the pound symbol missing (at least in Edge on Windows [Edit: And Safari on MacOS]), but the symbol is actually there if you download the file and open it locally.

The UK territory contains Currency SETS "" with the pound symbol missing (at least in Edge on Windows [Edit: And Safari on MacOS]), but the symbol is actually there if you download the file and open it locally.

StrongED shows there to be 6 instances of “£” in the downloaded file, none of which appear in the browser.

Even more interestingly the comment table at line 127 shows four empty lines, it should be :-

;-----------------------------------------------------------------------------
; Tables for Territory_CharacterPropertyTable (PRM 3-826)
;-----------------------------------------------------------------------------
;
; Note that the binary numbers in the flag tables have to be read backwards.
; The table below should help in this:

                ; 10987654321098765432109876543210
                ; ?>=<;:9876543210/.-,+*)('&%$#"!
                ; _^]\[ZYXWVUTSRQPONMLKJIHGFEDCBA@
                ;  ~}|{zyxwvutsrqponmlkjihgfedcba`
                ; üûùúõöôòóñïîìíëêèéçåãäâàáÜÖÑÉÇÅÄ
                ; øæΩºª∫π∏∑∂µ¥≥≤±∞ØÆ≠¨´™©®ß¶•§£¢°†
                ; flfi›€€⁄Ÿÿ◊÷’‘”“—–œŒÕÃÀ …»«∆≈ƒ√¬¡¿
                ; ˇ˛˝¸˚˙˘¯˜ˆıÙÛÚÒÔÓÌÏÎÍÈËÁʉ„‚·‡

Even more interestingly the comment table at line 127 shows four empty lines

The common denominator is the presence of top-bit-set characters. Best guess is that the Gitlab viewer is expecting UTF-8 and is barfing on ISO8859/1.

Meanwhile, I’ve noticed what appears to be a bug in the GitLab viewer. The UK territory contains Currency SETS "" with the pound symbol missing (at least in Edge on Windows [Edit: And Safari on MacOS]), but the symbol is actually there if you download the file and open it locally.

Part of the general problem with £ is that the USA thinks this # is a “pound symbol”

The larger part is as Stuart has pointed out – top-bit-set characters.
In this we have problems because of a lack of proper UTF support, and part from the ancient history of the insane use of the top-bit-set character values. Handy back on a Beeb, should have been ditched on ARM.

this we have problems because of a lack of proper UTF support

No, this isn’t our problem. This rests firmly on the head of GitLab. If it wants to speak Unicode, it has a responsibility to understand that there is a lot of code out there that is in various incarnations of eight bit character set. Such as older Windows code and RISC OS (which would mostly be covered by supporting CP-1252), anything for DOS (CP-437?) etc etc etc.

Converting these sources to Unicode is not the right answer, as that breaks them at source just to appease the CMS. The only correct solution is to keep the files in their native character set and have GitLab translate for display. Anything else is, simply, inadequate.

https://gitlab.com/gitlab-org/gitlab/-/issues/34874

insane use of the top-bit-set character values. Handy back on a Beeb, should have been ditched on ARM.

ISO 8859-1 was at least a standard when we were writing Arthur/RISC OS 2. Remind me when the Unicode standard was published, Steve?

Remind me when the Unicode standard was published, Steve?

First draft 1988, first published volume 1991 ?

So, somewhat too late for RISC OS 2, huh? And a good thing perhaps… The lack of half-word load/store on ARM would have made UCS-2 (as it was then) character processing that much slower for little discernible gain at the time. I think the code size increase involved would have left RISC OS 2 overflowing the ROM. Remember the pitiful clock speeds and memory available to most consumers? A305 – let’s waste half of that storage. For 8-bit characters, you can construct a simple upper-case/lower-case/collation-order/character-classification table in one kilobyte. For 16-bit characters, that’s (64Kb*2)*3+64Kb=448Kb. Indeed, ISO 8859-1 was still pretty new when we kicked it off in 1986. (Amusing aside. Tim was once asked by manglement what character standard we supported: “Arthur ASCII”)