ResFinder

Hi,

For some reason my Pi is set to country “default” which causes various applications, such as !Director, to crash. The cause is the “ResFind” program, which doesn’t handle such a thing.

So I decided to write something better – ResFinder.

http://www.heyrick.co.uk/random/ResFinder,ff8

It looks and feels like the original ResFind It looks and feels like a cut-down mini-ResFind – to the degree that if you rename it accordingly, it should function as a drop-in replacement for the mini version. This is by intention.

Unlike (mini) ResFind, I don’t bother asking the OS what the current country is. I ask the Territory module, for it is that which will be handling such things in this day and age. You can choose which behaviour you prefer.

I look for resources in the following locations:

• <[appname]$Dir>.Resources.[territoryname]

If that does not exist, it will revert to UK and try:

• <[appname]$Dir>.Resources.UK

If that does not exist, it will revert to unspecified and set:

• <[appname]$Dir>.Resources

It does not test for the existence of the latter case.

There is some additional functionality planned, I’m waiting on an allocation request for the system variables.

Written in assembler. Sources not currently available; though I will say that it is written in assembler. That’s why it is 888 bytes in size.
I was originally going to write it as a “Utility”, but IIRC later versions of Select (Adjust?) choke on files without correct headers, so “Absolute” it is then…

The whole point of ResFind was not to use the Territory module and mechanism. Mainly because there were very few territory modules available, and many people preferred using the OS in its native language, but apps in their native language. Or not, because ResFind easily allows choosing on a per-app basis.

Rick, I haven’t had a chance to check your offering out, yet.

Have you seen this? (Could only reach it on the Wayback Machine):

http://web.archive.org/web/20080827233513/http://foundation.riscos.com/html/features/03/duk/languk.htm

For some reason my Pi is set to country “default” which causes various applications, such as !Director, to crash

Rick,
Have you tried the latest beta?
https://sourceforge.net/projects/director/files/latest/download

My Pi is set with country = “default” and the beta fixes those issue for me :) .

and many people preferred using the OS in its native language, but apps in their native language.

Is this because the translations were bad? I’m trying to work out why somebody might prefer the OS in English as opposed to their native language, when they would appear to prefer apps in their native language?

Or not, because ResFind easily allows choosing on a per-app basis.

? I have not looked at ResConf, but I can imagine that this can only be altering the *Country setting. Or are there different incarnations of ResFind that behave differently? The one in Director reads the country setting.
You know that setting the country has side effects, right? PRM3-799 says “*Country selects the appropriate alphabet and keyboard layout for a given country.”.

Still, if this method is what is preferred, ResFinder can be easily tweaked to work that way… Or maybe a smarter options parser to permit both ways via a command line option? Mmm…

Have you tried the latest beta?

Actually, I have never used Director before. It is part of the Pi image so it was something in $.Apps that I tried running. I suppose I should have dropped in my resource locator and given it a whirl… but Noragami arrived and, well, you know how it is… :-)

You can override the default country by doing something like set CDVDBurn$Language Germany (for the obvious example: CDVDBurn :-)). ResConf could do that, too – but unfortunately it is not 32bit compatible (and has various problems on newer RISC OS versions even on 26bit machines).

The reason for people preferring the OS in English is that e.g. the German territory was always a 3rd party thing. You upgrade the OS and ye olde territory does not run anymore. What is more, it took a long time until the first German territory arrived – it was the seldomly used RISC OS 3.19. It took a year after RPC (RISC OS 3.50) release until the German territory arrived. So most users were used to the UK nature of the OS (and believe me, some of the german words used in the translation sound really strange if you are used to the english ones!), and sticked to it.

Still, many people prefer apps in their native language. Even in “Denglish Germany”, functional wording is in German, people are used to it because they read it all the time on the internet and in magazines. So it is much easier to use an app which provides the same wording that you are used to. And many people are “dual OS” users. If you are used to the german version of Microsoft Word (and it is nearly impossible to get an english Windows and Word in Germany!), it is much easier to switch between Word and the german version of TechWriter than the english version.

To be honest, I haven’t looked at it too closely, but at first sight the ResFind in the Director package doesn’t even remotely resemble the real ResFind as created by Olaf and Herbert.

ResFinder (which has now been allocated) will be more in the spirit of the smaller incarnation of “ResFind”.
Some extras to come, then source to ROOL.
Which begs the question – perhaps it could be a system module? Shouldn’t be hard to make it so…?

Okay. First “real” release of ResFinder is now available.

Syntax: ResFinder <appname> [<resources variable>] [-useos]

Operating like the mini-ResFind in !Director (and some other apps), it will look for appropriate language resources for the <appname> specified. If a <resources variable> is given, this will be set; otherwise ResFinder will set the variable appname$Path to point to the language resources.
The -useos option selects between reading the language of the system Territory (default) or reading the Country setting (-useos).

As an addition, ResFinder will enquire the platform “class” (26 bit, 32bit: RiscPC-like, Iyonix, OMAP3, OMAP4, RPi) and set a system variable for this that may be used in Obey files and such.

The software is notionally released under the EUPL¹. Sources are not available yet, though if nobody gets back to me to say “oh my god it killed my kitten!”² I can look to sorting that out soon. It is hand-crafted assembler, builds with objasm.

(-: Go look at ResFinder! :-)

¹ If ROOL are interested in adding this to their selection, I’m happy to offer sources, and under Castle licence. Mail me…

² Tested with a variety of fake apps on a Pi, RPCEmu (SA110), RedSquirrel (ARM7), and !A310Emu (ARM3).

Nice one, Rick.

I’m not sure how it works with the Territory Manager. Do territories set the system alphabet? And if they do, which has priority, *configure country or *configure territory?

Being an English speaker, I don’t really have much experience in this; though I suspect that the Territory sets the base configuration and specific country/alphabet/keyboard settings modify this.
I base this upon the fact that my machine only has the one Territory by default, yet I can specify an AZERTY keyboard, set the country to France, etc. this would leave a machine with English language ROM (Territory=UK) and French country (Country=France). Could even have French Country and British Keyboard. ;-)

I’ll let Steffen elaborate if I have anything wrong…

Does anybody know a quick way to get more Territories to be included in the ROM? I tried adding “France” to the Components file (after UK) but the ROM just built with UK only.

The second “real” release of ResFinder is now available.

http://www.heyrick.co.uk/software/resfinder/

Following an interesting email, this version of ResFinder will now put a terminating ‘.’ at the end of custom paths that end “$Path”. This is due to instances where an app developer might want to have the application path point to the application directory (say, for static data files and such) but also have a resources path to point to the language-specific resources.

I have not changed the default behaviour of altering <app>$Path because anything else is outside of the allocated namespace. However, to use the style of <app>Res$Path, you simply call ResFinder as follows (assuming “Sakura” is the application in question):
Run <Sakura$Dir>.ResFinder Sakura SakuraRes$Path

This brings to mind a question I would like to raise with ROOL.
As it stands, RISC OS offers a “path” which you can use to access files like “Sakura:Blah”. We cannot add another path – for if we had “Sakura$Path” and “Sakura$ResPath”, what would “Sakura:” be?
Given that the original “ResFind” has been around for a long time, and has a fair amount of use, in the absence of anything specific from Acorn and/or in the Style Guide, it has become a de facto standard, has it not? I considered using *Res$Path myself at first.

Therefore, given a potential need to point to language specific resources in addition to having a pointer to the application’s generic resources…
…would it be possible to add *Res$Path to the list of what you are entitled to use when you make an application allocation? Not *Res$<anything>, just very specifically *Res$Path. This can be marked off as specifically pointing to language-specific resources; using either my software, the original ResFind, or anything else devised along the way.

RFC?

I’m not sure I completely follow your question.

Normally, you’d have <App$Dir> to point to the stuff immediately within your application. You could then have <App$Path> to point to one or more locations as you see fit (by using “App:Something”). Maybe that’s what you use to locate your resources. Or, you can have <AppRes$Path> if you’re wanting to somehow disambiguate the application directory from the path of its resources (by using “AppRes:Something”). It doesn’t make much sense to have that as a default allocation because it’s very application-specific; if you want it, request it with your allocation.

I’ve no idea what <App$ResPath> is supposed to be – I’m pretty sure if the system variable doesn’t end with $Path, then it’s not a path variable. Was that a typo?

…would it be possible to add *Res$Path to the list of what you are entitled to use when you make an application allocation? Not *Res$, just very specifically *Res$Path. This can be marked off as specifically pointing to language-specific resources; using either my software, the original ResFind, or anything else devised along the way.

Would App$Res$Path work? It would avoid the need to modify the name reservation rules. However I’m not sure offhand if “App$Res:Something” would work correctly as a filename.

I’m not sure offhand if “App$Res:Something” would work correctly as a filename

 File name 'App$Res:Something' not recognised 

Maybe that’s what you use to locate your resources.

That was the idea behind modifying the app’s Path (ResFinder’s default behaviour). Not everybody agrees with this, however.

It doesn’t make much sense to have that as a default allocation because it’s very application-specific; if you want it, request it with your allocation.

That would be a workaround, yes…

I’ve no idea what <App$ResPath> is supposed to be – I’m pretty sure if the system variable doesn’t end with $Path, then it’s not a path variable. Was that a typo?

No, it was an example of an idea considered and rejected.
App$Path for the app path.
App$ResPath for the resources path.
Now what does “App:” mean? The path or the resources path? As it can’t be distinguished, having $ResPath mimic $Path’s behaviour is a non-starter.

As much as it pains me – the differentiation must come before the ‘$’. Which throws it out of the ordinarily-allocated namespace.

Would App$Res$Path work?

I tried that. I don’t think the parser likes expanding double-$ names in that way.

as much as it pains me – the differentiation must come before the ‘$’. Which throws it out of the ordinarily-allocated namespace.

Not necessarily, you could set App$ResPath and have the application read its value. The value would be passed to things like OS_File as a path string.

Only if you wish to pass the path to the command line would there be a problem as it doesn’t accept path strings, only variables of the form App$Path (there must only be one $¹).

Actually passing to the CLI from an application would work if you canonicalise first so it’s only really a problem in Obey files.

¹ When altering StrongED’s usage of paths several years ago I tried real hard to avoid non-standard path variables by using things like App$Res$Path but couldn’t make it work.

Not necessarily, you could set App$ResPath and have the application read its value. The value would be passed to things like OS_File as a path string.

…which is rather more than loading “App:Templates”, is it not? The purpose is to reduce the amount of code by using existent system facilities…

…which is rather more than loading “App:Templates”, is it not?

Of course, I was merely trying to show that it can be done without resorting to non-standard path variables.

Up to now I had not really thought much on this thread, but looking back I think there might be something pertinent to add.

First, if you are using the Toolbox your Res and Messages files are made international by adding the Country number as a suffix. This is not the same way as ResFind[er] works, so is this difference worth thinking about? If you are using the Toolbox, would you want other resource files to follow its standard or the ResFind one? It does seem appropriate to use the Country rather than Territory for the reasons given above.

Second, none of the ResFind[er] versions seems to exploit the nature of path variables, that they can include several paths to be searched in turn. I knocked up a small BASIC utility just to set a system variable with the Country name, which allows more flexibility than ResFind[er], I think:

  Run <Obey$Dir>.SetCountry
  Set MyApp$Path <Obey$Dir>.Resources.<Country>.,<Obey$Dir>.Resources.UK.,<Obey$Dir>.Resources.

You could be even more flexible, leaving out paths or including a ResourceApp path, and not just be limited to what ResFind gives you. The sytem variable could probably be a code variable, so you would not even have to have a separate file to set it.

This is not the same way as ResFind[er] works, so is this difference worth thinking about?

Mmm – trust Toolbox to do something else. That said, there are a variety of options of how to do this. Looking at some of the programs I have:

Calendar – D, F, NL, UK, Wales (a sort of bastardised version)
Director – France, UK (country names – same method I use)
NetSurf – de, en, fr, it, ja, nl (using ‘official’ country short codes)
Omni – UK
SparkFS – France, Germany, Netherland¹, UK
Store – UK
StrongEd – Global, UK (‘global’ is an interesting addition!)
StrongHelp – France, Germany, UK
Zap – France, Germany, UK (and some other stuff like “400” and “Tiles”)
DigitalCD – 1, 6 (huh? )
PrintPDF – UK
MakeModes – UK
PrivatEye – UK
Snapper – UK
SyncDiscs – UK
USBInfo – Netherlands¹, UK

With the exception of MakeModes, all of the above are !<app>.Resources.<country>. MakeModes has it directly in the app directory, not a Resources subdir.
DigitalCD looks like it is preferring a country code – it looks to be all by its lonesome. ;-)

Furthermore, some parts of StrongEd use Res files in country name directories – DigDirSED.!Languages.Resources.UK.res ;-)

I don’t have a lot of software installed (basically the default Pi distro, DDE, and some other bits), however I’ve looked for “Res*” and not a single “res” file has a number following.

Thus, I think it is pretty much a de-facto “standard” to use !app.Resources.CountryName.

And, along the way, I met a vast number of applications which have no possibility of being internationalised without altering the code – CloseUp, Maestro, Squash, Allocate, Flasher, MineHunt, Patience (are you seeing a trend?), ChangeFSI, all of the !Configure and plugins…yay Acorn for setting a good example!

Second, none of the ResFind[er] versions seems to exploit the nature of path variables,

This was pointed out to me. It didn’t really click in my head. It should have, following the…… <be polite> Run$Path. It will make the code a whole pile more complicated, but it should be do-able to scan the paths (as above) and build up a longer path string that way.

The ultimate aim is for the main program to access resources like “Sakura:Templates” and the right ones will load.

¹ Interesting side-note re. 10 character filename limitations; I’ll need to see how older versions of RISC OS cope with this – gracefully, I think, but best to confirm…

I don’t have a lot of software installed (basically the default Pi distro, DDE, and some other bits), however I’ve looked for “Res*” and not a single “res” file has a number following.

The default Pi distribution only contains UK resources, so that’s not a conclusive search. That scheme is used by people translating RISC OS though, otherwise internationalisation bugs would never happen.

Applications generally fall into one of two camps, either

• Toolbox app, so the toolbox picks up ResN or MessageN preferentially before falling back to Res and Messages
• Wimp app, with a Templates and Messages files

The Style Guide (chapter 17) lists those files in a typical application, and implies that you supply the main application in english along with skeleton applications (one for each translation) which are then copied over the top to swap language by overwriting Messages and Templates. What the toolbox (and ResFind(er)) are doing is refining that to allow all the translations to be bundled and for the computer to select the most appropriate one at run time.

It’s also worth a quick glance at App$Resources (in System Variables in PRM 4) and App$Messages (in PRM 5a) which appears to be intended to point to the current set of resources, though not with an eye to internationalisation as far as I can see.

all of the !Configure and plugins

They’re all Toolbox applications, so look for ResN and MessageN as noted above.

Possibly the easiest way to lassoo the majority of Wimp apps would be to modify Wimp_OpenTemplate and MessageTrans_OpenFile to spot a default leafname (Templates and Messages respectively) and act like the toolbox and first try to open TemplatN and MessageN.

Those with more complex resource requirements then continue to use ResFind(er) to point App$Resources or equivalent.

A variant could be to have Territory Manager leave the territory number in a system variable, then people’s !Run files could contain something like

Set App$Messages <App$Dir>.Messages
IfThere <App$Dir>.Message<Territory$Number> Then Set App$Messages <App$Dir>.Message<Territory$Number>

It would seem to be necessary to accomodate the country number suffix in any internationalisation scheme, if only for the many Toolbox apps.

I like the idea of implementing such a scheme for normal wimp apps through their Messages and Templates files, but this could not be backward compatible with machines running current and older versions of RO.

@Rick
Of all those apps you list, how many use a version of ResFind and how many use a configuration option for the language, as NetSurf does?

As I see it, an automatic language choice can only use the list of countries in the OS, whether that is made through the Country or Territory. That is not a comprehesive list and it includes some oddities, such as DvorakUSA. It does not really tie in with the way the discussion on Territories was going a while back.

If those countries are the only ones that can be dealt with automatically, then setting up a path variable in the ‘!Run’ file in some way similar to what I suggested would seem to be a lot simpler and more flexible for the author of an application than trying to construct paths in some version of ResFind.

It will make the code a whole pile more complicated, but it should be do-able to scan the paths (as above) and build up a longer path string that way.

The OS provides the path variable facility already and it is not complicated.

The ultimate aim is for the main program to access resources like “Sakura:Templates” and the right ones will load.

My sugestion does precisely that. It looks first in the ‘Country’ directory, then in ‘UK’ and failing that in the parent ‘Resources’. You would expect to find non-international files, such as ‘Sprites’ there. As I see it, ResFind[er] has to have copies of such files in the country directories, which seems a waste.

I have mostly attempted to set up my software so that it could be international if someone were inclined to do it. I have been swayed by this thread into reconsidering the Toolbox method and implementing only international resources directories.

Quite a number of things I have written have been modules, which means that there is yet another aspect to this.

To make a module capable of being international you make all the text references to a ‘Messages’ file, which is registered with ResourceFS in its own named directory; replacing this file changes the text references. To do this there has to be another module that can register the replacement. I wrote my own ‘RFSFiles’ module to make this a possibly user-level option, but better overall would be a single ‘Country’ module that would register all the Messages files that have been translated.

Has anyone any further thoughts on this?

To add just one more factor, there is the ‘!Territory’ app from the German branch of the family that attempts to solve some of these problems. I found it a bit too idiosynchratic, but it does have a Utility file called SetTerr that does something similar to my SetCountry. ;-)

It would seem to be necessary to accomodate the country number suffix in any internationalisation scheme

“seem”? In my personal experience, it would appear that country-name directories is a lot more common.

if only for the many Toolbox apps.

I finally found one that has internationalised Toolbox resources. The demo of !DiscKnight… Messages7, Messages, Res, Res7 all present within the base directory. Is this how Toolbox does it? If so, any discussion between how ResFind[er] and Toolbox work is moot as Toolbox would appear (from this example) to not even use directories. [out of interest, can Res files contain sprites? is it possible to internationalise sprites via toolbox’s method?]

Of all those apps you list, how many use a version of ResFind and how many use a configuration option for the language, as NetSurf does?

Calendar – hardcoded in the !Run file
Director – mini-ResFind
NetSurf – custom method (and offers more choices than actually exist!)
Omni – built-in method, uses CLib so I’m not able to easily trace how
SparkFS – full version of ResFind
Store – hardcoded to UK in !Run file
StrongEd – full version of ResFind
StrongHelp – full version of ResFind
Zap – custom using Zap$Country (etc) in !Run file
DigitalCD – custom program similar to ResFinder (written in C, ten times larger!)
PrintPDF – built-in detection
MakeModes – bizarrely, doesn’t appear to use the UK resources at all…?
PrivatEye – full version of ResFind
Snapper – hardcoded in !Run file
SyncDiscs – hardcoded in !Run file
USBInfo – full version of ResFind

It would appear that:

2 use configuration option (NetSurf/Zap)
5 use ResFind (possibility to specify a language)
5 use custom or mini-resfind-like
4 just set “UK” in the !Run file (regardless of the presence of other language files)
1 is a misnomer, shouldn’t be on the list

Does that answer your question?

That is not a comprehensive list and it includes some oddities, such as DvorakUSA.

Yes, I noticed that. Still, it’s a far better list than we’re likely to achieve in practice. Still can’t assume anything written in “squiggles” (where “squiggles” is any non-Latin language) will have a hope of working…

The OS provides the path variable facility already and it is not complicated.

I meant modifying my code for the new behaviour.
As it turns out, it wasn’t so hard…

As I see it, ResFind[er] has to have copies of such files in the country directories, which seems a waste.

Not any more, for ResFinder. It builds a full path string, so things like:

!Sakura.Resources.France.!Help
!Sakura.Resources.UK.!Help

will show the UK one to UK people, the French one to French people, and the UK one to any other (currently unsupported) language.
This is much more flexible.

Quite a number of things I have written have been modules, which means that there is yet another aspect to this.

ResFinder isn’t really aimed at module code – one could, I suppose, use the path to load something into ResourceFS?

To make a module capable of being international you make all the text references to a ‘Messages’ file, which is registered with ResourceFS in its own named directory; replacing this file changes the text references. To do this there has to be another module that can register the replacement.

Sounds a bit chicken-and-egg – can’t a module load its own resources at start-up?

The third “real” release of ResFinder (v0.04) is now available.

http://www.heyrick.co.uk/software/resfinder/ (38K)

In addition to the past, and following emails and discussion here, this version of ResFinder will now build a composite path of all the available parts, such as: “<Sakura$Dir>.Resources.UK.,<Sakura$Dir>.Resources.,<Sakura$Dir>.”.
Custom non-path system variables will have only the language part, as was previously the case, as this behaviour is specific to paths.