People,

See the following function :

void printValue(int value){
    	printf("The value is :");
    	printf('%d', value);
}

    	Internationalization is a big issue in these days. The one of
strategies adopted is the use of translators, like gnu gettext package,
which extract strings from source code and generate a new file for
translation. This file is recombined later during compilation.
    	This can't be the best way, but is a simple and is very common.
    	Problem is not all strings must be translated ! And there are not a
way of marking "text" and utility strings.
    	Why not differ the meaning of double quotes and single quotes for
this pourpose ?

double quotes (") : text for translation.
single quotes (') : constants for general use.


    	Maybe someone have a nicer idea.

Juarez

That's a great idea, but the ' and " functionality is pretty well settled in
D by now. How about, say, putting a unique comment before the strings to be
translated, like:
    print(/*T*/"this string gets translated");


"Juarez Rudsatz" <juarez@correio.com> wrote in message news:Xns922C927DA4780juarezcom@63.105.9.61...
> People,
>
> See the following function :
>
> void printValue(int value){
>     printf("The value is :");
>     printf('%d', value);
> }
>
>     Internationalization is a big issue in these days. The one of
> strategies adopted is the use of translators, like gnu gettext package,
> which extract strings from source code and generate a new file for
> translation. This file is recombined later during compilation.
>     This can't be the best way, but is a simple and is very common.
>     Problem is not all strings must be translated ! And there are not a
> way of marking "text" and utility strings.
>     Why not differ the meaning of double quotes and single quotes for
> this pourpose ?
>
> double quotes (") : text for translation.
> single quotes (') : constants for general use.
>
>
>     Maybe someone have a nicer idea.
>
> Juarez

Might there be a place for language support of this?  Something like version,
maybe?
    print( language( "EN_US" -> "this string gets translated",
                            "LATIN_PIG" -> "isthay ingsytray etsgay
anslatedtray") );
I don't like the inline syntax, though.  Maybe a simple tag on the string:
    print( translate "this string gets translated" );
With a table elsewhere in the source code:
    translate-table "this string gets translated"
    {
        "EN_US" -> "this string gets translated",
        ...
    }

Walter wrote:

> That's a great idea, but the ' and " functionality is pretty well settled in
> D by now. How about, say, putting a unique comment before the strings to be
> translated, like:
>     print(/*T*/"this string gets translated");
>
> "Juarez Rudsatz" <juarez@correio.com> wrote in message news:Xns922C927DA4780juarezcom@63.105.9.61...
> > People,
> >
> > See the following function :
> >
> > void printValue(int value){
> >     printf("The value is :");
> >     printf('%d', value);
> > }
> >
> >     Internationalization is a big issue in these days. The one of
> > strategies adopted is the use of translators, like gnu gettext package,
> > which extract strings from source code and generate a new file for
> > translation. This file is recombined later during compilation.
> >     This can't be the best way, but is a simple and is very common.
> >     Problem is not all strings must be translated ! And there are not a
> > way of marking "text" and utility strings.
> >     Why not differ the meaning of double quotes and single quotes for
> > this pourpose ?
> >
> > double quotes (") : text for translation.
> > single quotes (') : constants for general use.
> >
> >
> >     Maybe someone have a nicer idea.
> >
> > Juarez

--
The Villagers are Online! villagersonline.com

.[ (the fox.(quick,brown)) jumped.over(the dog.lazy) ]
.[ (a version.of(English).(precise.more)) is(possible) ]
?[ you want.to(help(develop(it))) ]

>     print( translate "this string gets translated" );
> With a table elsewhere in the source code:
>     translate-table "this string gets translated"
>     {
>         "EN_US" -> "this string gets translated",
>         ...
>     }

I like the syntax, but I think the translation table would be better in a separate file, to avoid clutter, but then that introduces a load of linking problems, or something...

Java's Internationalization with resource bundles works like this, but relies on being able to dynamically load classes, which I seem to remember reading, D can't do. Java's Resource Bundles did however allow people to write message texts in any language with out altering the program...

I'm sure their is a middle ground...

On the whole I think internationalization and localization are better performed outside of the actual language...

Alix Pexton...

Hi,

"Alix Pexton" <Alix@seven-point-star.co.uk> wrote in message news:01c2130b$8818f460$90ac7ad5@jpswm...

> I like the syntax, but I think the translation table would be better in a separate file

Absolutely. The best translations is done by experts in spoken languages, not programming languages. They should never need to see the source code.

Also, using resource files allows you to develop in one language, and let someone else do the translation - someone that is not entitled to see the source code, eg. a customer or system integrator of a commercial product. Another benefit is that you can ship resource files for multiple languages with the product and let the end user choose among them. Then you have only one product. If you choose language at compile time (or build time), it will add an extra dimension to the product making it more costly to maintain and support.

Another thing to consider is positional parameters like the format specifiers of printf(). The order of the parameters will vary from language to language, and well designed internationalization support will support this as well. Windows' FormatMessage() does this, and so does GNU's printf() - see http://www.gnu.org/manual/gettext-0.10.35/html_node/gettext_17.html

I'm not sure anything is gained by building support into the D language, though. A library solution would do just as well. Consider Walter's proposal:

    > print(/*T*/"this string gets translated");

It could just as well be:

    print(T("this string gets translated"));

It is even shorter, and it could easily support resource files. If it was supplemented with a GNU style sprintf() without buffer allocation problems, everything above could be achieved. In D, in would like an sprintf() having a proto like this:

    char[] sprintf(char[] format, ...);

> On the whole I think internationalization and localization are better performed outside of the actual language...

Agreed :-)

Regards,
Martin M. Pedersen

Martin

You are right in it being a big issue, and that probably should not be solely left to code.

One (and it pains me to say so) good thing about C# is that they have an alternate printf syntax, such as

    if(language == 1)
    {
        fmtStr    =    "This {0} is {2} the {3} format {1} text";
    }
    else
    {
        fmtStr    =    "Bonjour {1} nous {0} sommes {3} discarde {2} le cup
de monde";    // Spot the linguist!
    }

    Console.WriteLine(fmtStr, arg0, arg1, arg2, arg3);

such that one can handle ordering in combination with resources strings.

Is there any such support in D?

Matthew

"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:aeat39$v70$1@digitaldaemon.com...
> Hi,
>
> "Alix Pexton" <Alix@seven-point-star.co.uk> wrote in message news:01c2130b$8818f460$90ac7ad5@jpswm...
>
> > I like the syntax, but I think the translation table would be better in
a
> > separate file
>
> Absolutely. The best translations is done by experts in spoken languages, not programming languages. They should never need to see the source code.
>
> Also, using resource files allows you to develop in one language, and let someone else do the translation - someone that is not entitled to see the source code, eg. a customer or system integrator of a commercial product. Another benefit is that you can ship resource files for multiple languages with the product and let the end user choose among them. Then you have
only
> one product. If you choose language at compile time (or build time), it
will
> add an extra dimension to the product making it more costly to maintain
and
> support.
>
> Another thing to consider is positional parameters like the format specifiers of printf(). The order of the parameters will vary from
language
> to language, and well designed internationalization support will support this as well. Windows' FormatMessage() does this, and so does GNU's printf() - see http://www.gnu.org/manual/gettext-0.10.35/html_node/gettext_17.html
>
> I'm not sure anything is gained by building support into the D language, though. A library solution would do just as well. Consider Walter's proposal:
>
>     > print(/*T*/"this string gets translated");
>
> It could just as well be:
>
>     print(T("this string gets translated"));
>
> It is even shorter, and it could easily support resource files. If it was supplemented with a GNU style sprintf() without buffer allocation
problems,
> everything above could be achieved. In D, in would like an sprintf()
having
> a proto like this:
>
>     char[] sprintf(char[] format, ...);
>
> > On the whole I think internationalization and localization are better performed outside of the actual language...
>
> Agreed :-)
>
> Regards,
> Martin M. Pedersen
>
>
>

This problem is easily solved by an enum index into an exterrnally linked array of static constant strings.

The problem with that is maintaining the parallel arrays.

Can the core problem with such be eased at all?

Sean


"Martin M. Pedersen" <mmp@www.moeller-pedersen.dk> wrote in message news:aeat39$v70$1@digitaldaemon.com...
> Hi,
>
> "Alix Pexton" <Alix@seven-point-star.co.uk> wrote in message news:01c2130b$8818f460$90ac7ad5@jpswm...
>
> > I like the syntax, but I think the translation table would be better in
a
> > separate file
>
> Absolutely. The best translations is done by experts in spoken languages, not programming languages. They should never need to see the source code.
>
> Also, using resource files allows you to develop in one language, and let someone else do the translation - someone that is not entitled to see the source code, eg. a customer or system integrator of a commercial product. Another benefit is that you can ship resource files for multiple languages with the product and let the end user choose among them. Then you have
only
> one product. If you choose language at compile time (or build time), it
will
> add an extra dimension to the product making it more costly to maintain
and
> support.
>
> Another thing to consider is positional parameters like the format specifiers of printf(). The order of the parameters will vary from
language
> to language, and well designed internationalization support will support this as well. Windows' FormatMessage() does this, and so does GNU's printf() - see http://www.gnu.org/manual/gettext-0.10.35/html_node/gettext_17.html
>
> I'm not sure anything is gained by building support into the D language, though. A library solution would do just as well. Consider Walter's proposal:
>
>     > print(/*T*/"this string gets translated");
>
> It could just as well be:
>
>     print(T("this string gets translated"));
>
> It is even shorter, and it could easily support resource files. If it was supplemented with a GNU style sprintf() without buffer allocation
problems,
> everything above could be achieved. In D, in would like an sprintf()
having
> a proto like this:
>
>     char[] sprintf(char[] format, ...);
>
> > On the whole I think internationalization and localization are better performed outside of the actual language...
>
> Agreed :-)
>
> Regards,
> Martin M. Pedersen
>
>
>

No doubt.  printf can *so* be improved upon;  I don't see it as the greatest thing since sliced bread.  For one many times you just want to format a string instead of do actual printing, and for this you use sprintf.  But sprintf (like printf) is C, and was designed over 20 years ago.  D doesn't work well with it.  It's not "native" D.

Surely we can do a wee bit better;  something array based like the rest of D strings work.  Maybe something with ~ array concatenation syntax and some kinds of conversion functions that return strings;

Perhaps we can have some standard way to pipe arrays to / from streams.  And to convert variables to / from arrays of char.

I'm no expert in localization so I'll leave that detail to someone else.

Sean


"Matthew Wilson" <matthew@thedjournal.com> wrote in message news:aebaa2$1ctn$1@digitaldaemon.com...
> Martin
>
> You are right in it being a big issue, and that probably should not be solely left to code.
>
> One (and it pains me to say so) good thing about C# is that they have an alternate printf syntax, such as
>
>     if(language == 1)
>     {
>         fmtStr    =    "This {0} is {2} the {3} format {1} text";
>     }
>     else
>     {
>         fmtStr    =    "Bonjour {1} nous {0} sommes {3} discarde {2} le
cup
> de monde";    // Spot the linguist!
>     }
>
>     Console.WriteLine(fmtStr, arg0, arg1, arg2, arg3);
>
> such that one can handle ordering in combination with resources strings.
>
> Is there any such support in D?
>
> Matthew

Matthew Wilson wrote:
[snip]
> One (and it pains me to say so) good thing about C# is that they have an
> alternate printf syntax, such as
> 
>     if(language == 1)
>     {
>         fmtStr    =    "This {0} is {2} the {3} format {1} text";
>     }
>     else
>     {
>         fmtStr    =    "Bonjour {1} nous {0} sommes {3} discarde {2} le cup
> de monde";    // Spot the linguist!
>     }
> 
>     Console.WriteLine(fmtStr, arg0, arg1, arg2, arg3);
> 
> such that one can handle ordering in combination with resources strings.
> 
> Is there any such support in D?

Since va_list gives no information about the type, size, or number of parameters, indexed conversion specifiers would either have to depend upon some beezarre format string analysis to figure out what the parameters are, a prefixed dictionary, as in "ssds:This %s is %:2d the %:3s format %:1s text", or preprocessing, as in gettext.  All three solutions are bug-inducing, and the first requires that all parameters to the highest one indexed get mentioned in the format string.

One stone can kill this bird and many others - I described a solution that fixes the problem more readily than generic objects (which don't address others that this solution does, such as constructing and destructing arguments to normal functions) in the "float -> double conversion" thread in early May.  Then, as with Python, most of the time you'd just use %s regardless of the type.

[snip]

Good points.

Far out, I seem to say a great many stupid things in my morning posts. :) Might have to save it all for the evenings ...

Matthew

"Burton Radons" <loth@users.sourceforge.net> wrote in message news:3D09B1FD.8060908@users.sourceforge.net...
> Matthew Wilson wrote:
> [snip]
> > One (and it pains me to say so) good thing about C# is that they have an alternate printf syntax, such as
> >
> >     if(language == 1)
> >     {
> >         fmtStr    =    "This {0} is {2} the {3} format {1} text";
> >     }
> >     else
> >     {
> >         fmtStr    =    "Bonjour {1} nous {0} sommes {3} discarde {2} le
cup
> > de monde";    // Spot the linguist!
> >     }
> >
> >     Console.WriteLine(fmtStr, arg0, arg1, arg2, arg3);
> >
> > such that one can handle ordering in combination with resources strings.
> >
> > Is there any such support in D?
>
> Since va_list gives no information about the type, size, or number of parameters, indexed conversion specifiers would either have to depend upon some beezarre format string analysis to figure out what the parameters are, a prefixed dictionary, as in "ssds:This %s is %:2d the %:3s format %:1s text", or preprocessing, as in gettext.  All three solutions are bug-inducing, and the first requires that all parameters to the highest one indexed get mentioned in the format string.
>
> One stone can kill this bird and many others - I described a solution that fixes the problem more readily than generic objects (which don't address others that this solution does, such as constructing and destructing arguments to normal functions) in the "float -> double conversion" thread in early May.  Then, as with Python, most of the time you'd just use %s regardless of the type.
>
> [snip]
>