The catgets implementation that is with FreeDOS edlin was one I wrote
myself after looking at kitten and noticing that it was too DOS-specific
(i.e. using low-level system calls to INT 21H to read and write to
files) and tiny. It only had the ability to open one catalog at a time.
I never looked at the ancient catgets.
According to sysv3, the header file where catgets and friends are
defined is called nl_types.h .
According to the susv3 standards (available for free from the Open
Group), NLSPATH contains a list of paths like printf format strings. The
format strings have the following conversions:
%N
The value of the name parameter passed to catopen().
%L
The value of the LC_MESSAGES category.
%l
The language element from the LC_MESSAGES category.
%t
The territory element from the LC_MESSAGES category.
%c
The codeset element from the LC_MESSAGES category.
%%
A single '%' character.
An empty string is substituted if the specified value is not
currently defined. The separators underscore ( '_' ) and period ( '.' )
are not included in the %t and %c conversion specifications.
Templates defined in NLSPATH are separated by colons ( ':' ). A
leading or two adjacent colons "::" is equivalent to specifying %N. For
example:
NLSPATH=":%N.cat:/nlslib/%L/%N.cat"
indicates to catopen() that it should look for the requested message
catalog in name, name.cat, and /nlslib/category/name.cat, where category
is the value of the LC_MESSAGES category of the current locale.
Users should not set the NLSPATH variable unless they have a
specific reason to override the default system path. Setting NLSPATH to
override the default system path produces undefined results in the
standard utilities and in applications with appropriate privileges.
[Option End]
The environment variables LANG , LC_ALL , LC_COLLATE , LC_CTYPE ,
LC_MESSAGES , LC_MONETARY , LC_NUMERIC , LC_TIME , [XSI] [Option Start]
and NLSPATH [Option End] provide for the support of internationalized
applications. The standard utilities shall make use of these environment
variables as described in this section and the individual ENVIRONMENT
VARIABLES sections for the utilities. If these variables specify locale
categories that are not based upon the same underlying codeset, the
results are unspecified.
The values of locale categories shall be determined by a precedence
order; the first condition met below determines the value:
1.
If the LC_ALL environment variable is defined and is not null, the
value of LC_ALL shall be used.
2.
If the LC_* environment variable ( LC_COLLATE , LC_CTYPE ,
LC_MESSAGES , LC_MONETARY , LC_NUMERIC , LC_TIME ) is defined and is not
null, the value of the environment variable shall be used to initialize
the category that corresponds to the environment variable.
3.
If the LANG environment variable is defined and is not null, the
value of the LANG environment variable shall be used.
4.
If the LANG environment variable is not set or is set to the empty
string, the implementation-defined default locale shall be used.
If the locale value is "C" or "POSIX", the POSIX locale shall be used
and the standard utilities behave in accordance with the rules in POSIX
Locale for the associated category.
If the locale value begins with a slash, it shall be interpreted as the
pathname of a file that was created in the output format used by the
localedef utility; see OUTPUT FILES under localedef. Referencing such a
pathname shall result in that locale being used for the indicated category.
[XSI] [Option Start] If the locale value has the form:
language[_territory][.codeset]
it refers to an implementation-provided locale, where settings of
language, territory, and codeset are implementation-defined.
LC_COLLATE , LC_CTYPE , LC_MESSAGES , LC_MONETARY , LC_NUMERIC , and
LC_TIME are defined to accept an additional field @ modifier, which
allows the user to select a specific instance of localization data
within a single category (for example, for selecting the dictionary as
opposed to the character ordering of data). The syntax for these
environment variables is thus defined as:
[EMAIL PROTECTED]
For example, if a user wanted to interact with the system in French, but
required to sort German text files, LANG and LC_COLLATE could be defined as:
LANG=Fr_FR
LC_COLLATE=De_DE
This could be extended to select dictionary collation (say) by use of
the @ modifier field; for example:
[EMAIL PROTECTED]
[Option End]
An implementation may support other formats.
If the locale value is not recognized by the implementation, the
behavior is unspecified.
At runtime, these values are bound to a program's locale by calling the
setlocale() function.
Additional criteria for determining a valid locale name are
implementation-defined.
The changes to support a DOS framework would be to have a semicolon
instead of a colon as a delimiter for rulesets, so to support the kitten
rulesets below, NLSPATH would have to be
"c:\NLSPATH\%L\cat;c:\NLSPATH\cat.%L". The name parameter given to
catopen isn't used at all. Your application isn't playing nice with all
the other applications that are using the system.
In other words, if somebody's LANG parameter is "en", then according to
the kitten rules, edlin's English-language catalog file would be called
c:\NLSPATH\en\cat or c:\NLSPATH\cat.en . The English-language catalogs
for other programs would have to have the same names as well, causing
headaches for whomever set up the system. It is possible to put the
catalogs for all the programs in the system into the same file, but that
would be a maintenance nightmare.
I am trying to fix this by doing it the right way: having a flexible
NLSPATH and LANG environment variables. I know we can make this work
without causing i18n headaches.
Gregory
Jim Hall wrote:
> On Sat, Aug 23, 2008 at 8:40 PM, Gregory Pietsch <[EMAIL PROTECTED]> wrote:
>
>> FreeDOS maniacs,
>>
>> I was playing around with the implementation of edlin as it has been
>> over a year since 2.10c, and was wondering if I could get rid of the
>> ancient kitten.c and kitten.h files in the implementation.
>>
>> I am currently trying to tweak the catgets.c implementation so that it
>> will be more Posix-like: relying on the environment variables LANG and
>> NLSPATH for the information needed to find message catalogs.
>>
>> I'm trying to make the edlin implementation be at the forefront of
>> innovation for FreeDOS. At the same time, Jim Hall might complain if I
>> killed kitten by replacing it with something better (the files
>> nl_types.h and catgets.c in edlin implement the catgets functionality)
>> and I don't want to hurt his feelings.
>>
>> What does everyone think about this?
>>
>> Gregory
>>
>>
>
>
> I doubt Jim would mind very much. :-) He says on his page
> <http://www.freedos.org/jhall/> that Kitten is not currently
> maintained, so he would probably be happy for someone to take this on
> and provide some updates. But that's just a guess - you might try
> emailing him. ;-)
>
>
> However, what version of Kitten or Cats do you have? (Kitten replaced
> Cats.) Was it a locally-written version for Edlin? (I've never looked
> at Edlin's i18n code.) You mentioned catgets.c, so I think Edlin must
> have an old version of Cats, although Cats didn't have its own
> nl_types.h.
>
> Kitten already uses LANG and NLSPATH to find the catalog files. The
> latest version of Kitten is "kitten-c"'.
> <http://www.ibiblio.org/pub/micro/pc-stuff/freedos/files/devel/libs/cats/kitten-c.zip>
>
> Like Catgets, when looking for a catalog, Kitten will scan the paths
> provided in NLSPATH to look for the catalog file. In Kitten, this is a
> very simple ruleset:
>
> For each path in NLSPATH {
> 1. look for: NLSPATH\LANG\cat
> 2. look for: NLSPATH\cat.LANG
> }
>
>
>
> -jh
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Freedos-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/freedos-devel
>
>
-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Freedos-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/freedos-devel
