i18n question.

[Benjamin Riefenstahl]

Hi Andrew,


tridge at samba.org writes:
> this argument doesn't convince me. As long as we stick to the
> "rules" as to what we can assume about a internal charset then we
> will be OK.

In the current system the rules are not a requirement on "us" but on
the users' file systems out there.  And not all of them conform to
those rules, that's a fact.

>  *) build a "charset translation" NTVFS module that can be used in
>  those less common cases where you wish to use a different charset
>  for some shares.

I like that approach.  You get your optimizations for filesystems that
conform to your rules, but you can use the charset translation module
for all others.

> On windows they have compiler support for wide characters but we
> don't on unix.  Without that compiler support it is a nightmare
> dealing with all of the string constants we have to deal with in
> CIFS.

I understand that point.  OTOH, there are ways around that, so the
"nightmare" part seems exaggerated to me.  Off the top of my head: Use
a simple preprocessor, use global constants and a preprocessor or
generator for the implementation file(s) of those strings, use a
version of sprintf() that takes an ASCII string as format parameter,
but generates UTF-16 (and similar for other functions).

Also, from a quick review, quite a considerable percentage of constant
strings in Samba are not for exchange with SMB, but configuration
options, error messages and other stuff that can just stay in ASCII.


benny