Accessing languages.catalog and countries.catalog

[trixie]

I'm working on a program that uses country and language names, which I naturally want to display localized. Considering that these are already available in the system's countries.catalog and languages.catalog, I think it would be quite absurd (and a waste of resources) if programs had to put country and language names in their own catalogs. I'd prefer if I could open the respective system catalog and retrieve the strings from there.

Would it be possible to publish the relevant locale string ID definitions as part of the SDK? So that a third-party program could request, for example, MSG_GERMANY from the system's countries.catalog.

[gazelle]

It's pretty easy.

For countries.catalog the IDs are derived from the ISO 3166 country code (alpha-3 names):

Code: Select all

...
MSG_AUS ($41555300//)
Australia
;
MSG_AUT ($41555400//)
Austria
;
...

And for languages.catalog it's the ISO-639-2/T 3-letter lowercase language code:

Code: Select all

...
MSG_eng ($656e6700//)
English
;
...
MSG_deu ($64657500//)
German
;
...

edit1: Of course an official list (or maybe function in one of the libs Get(Countries|Languages)List)) would be better.

edit2: As catalog files are in IFF format, you can also use iffparse.library to read them.

[broadblues]

Accessing the catalogs directly in such a way would be a bad idea, restricting the OS devs from updating them in any way they see fit.

IMHO, if such a feature was added it should be via the locale.library API.

And it does seem like a good idea.

[nbache]

It is already done in the Locale prefs editor, presumably.

It would be interesting to know how it goes about it. Maybe there is already an appropriate function which would just need to be exposed publically.

Of course, it would probably already be possible to do it with existing public functionality by opening languages.catalog repeatedly for each of the languages - but quite cumbersome.

Best regards,

Niels

[xenic]

@trixie
The ctlg2ct.lha file at OS4Depot includes sources that have an IFF parse of catologs in the code which might be a good example for you to get the language names from within your program.

[trixie]

@broadblues

Accessing the catalogs directly in such a way would be a bad idea, restricting the OS devs from updating them in any way they see fit.

That is true.

IMHO, if such a feature was added it should be via the locale.library API.

I agree - although I don't hold out much hope for that being added any time soon.

[javierdlr]

@broadblues

Accessing the catalogs directly in such a way would be a bad idea, restricting the OS devs from updating them in any way they see fit.

That is true.

IMHO, if such a feature was added it should be via the locale.library API.

I agree - although I don't hold out much hope for that being added any time soon.

Maybe you can take a look into SDK's example 'Locale' drawer and make_country_files.c file as it creates the .country files and helps you somehow:

...
struct CountryData
{
STRPTR cd_Name;
ULONG cd_Charset; /* TetiSoft: If this is non-zero, */
STRPTR cd_NativeName; /* this is the name in this charset */
STRPTR cd_Version;
struct CountryPrefs cd_Prefs;
};
...

[jaokim]

Accessing the catalogs directly in such a way would be a bad idea, restricting the OS devs from updating them in any way they see fit.

IMHO, if such a feature was added it should be via the locale.library API.

Without knowing how the OS devs work, I'd reckon someone changing the naming from ISO standards to something different, is less likely then someone adding a function for it (which I think is already very unlikely [hopefully that remark will persuade someone to do it ]).
But I'd say: use the catalogs, but make sure to check the version of the catalog! The likelihood of the namng standard changing without version bumping should be zero. Perhaps even include a hidden feature to disable the catalog lookup if it should change in the future, and the sources to whatever you're making should be lost.
Btw: how does locale do catalog search? Is CURRDIR: the first path to search? If so, then any incompatible changes could be fixed that way.

[javierdlr]

Accessing the catalogs directly in such a way would be a bad idea, restricting the OS devs from ...

Btw: how does locale do catalog search? Is CURRDIR: the first path to search? If so, then any incompatible changes could be fixed that way.

SDK's ILocale->OpenCatalog():
...
Since V50, the function searches for catalogs in this directories:

PROGDIR:Catalogs/languageName/name
LOCALE:Catalogs/languageName/name
PROGDIR:Catalogs/languageName_UTF-8/name
LOCALE:Catalogs/languageName_UTF-8/name
PROGDIR:Catalogs/languageName_US-ASCII/name
LOCALE:Catalogs/languageName_US-ASCII/name