Page 1 of 1

Accessing languages.catalog and countries.catalog

PostPosted: Sat Apr 23, 2016 1:39 pm
by 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.

Re: Accessing languages.catalog and countries.catalog

PostPosted: Sat Apr 23, 2016 4:05 pm
by 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.

Re: Accessing languages.catalog and countries.catalog

PostPosted: Sat Apr 23, 2016 4:28 pm
by 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.

Re: Accessing languages.catalog and countries.catalog

PostPosted: Sun Apr 24, 2016 1:58 am
by 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

Re: Accessing languages.catalog and countries.catalog

PostPosted: Sun Apr 24, 2016 6:52 pm
by 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.

Re: Accessing languages.catalog and countries.catalog

PostPosted: Mon Apr 25, 2016 10:44 am
by trixie
@broadblues

broadblues wrote: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.

Re: Accessing languages.catalog and countries.catalog

PostPosted: Tue Apr 26, 2016 12:22 am
by javierdlr
trixie wrote:@broadblues

broadblues wrote: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;
};
...

Re: Accessing languages.catalog and countries.catalog

PostPosted: Wed Apr 27, 2016 7:56 pm
by jaokim
broadblues wrote: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.

Re: Accessing languages.catalog and countries.catalog

PostPosted: Thu Apr 28, 2016 2:02 pm
by javierdlr
jaokim wrote:
broadblues wrote: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