Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.misc > #2031 > unrolled thread

Issuing a message in the language of the user

Back to article view | Back to comp.lang.misc

Contents

  Issuing a message in the language of the user "James Harris" <james.harris.1@gmail.com> - 2014-04-27 20:29 +0100
    Re: Issuing a message in the language of the user "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> - 2014-04-28 09:24 +0200
    Re: Issuing a message in the language of the user "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 03:45 -0400
      Re: Issuing a message in the language of the user "James Harris" <james.harris.1@gmail.com> - 2014-04-28 18:15 +0100
        Re: Issuing a message in the language of the user "BartC" <bc@freeuk.com> - 2014-04-28 19:09 +0100
        Re: Issuing a message in the language of the user "Rod Pemberton" <dont_use_email@xnothavet.cqm> - 2014-04-28 20:33 -0400
    Re: Issuing a message in the language of the user "BartC" <bc@freeuk.com> - 2014-04-28 09:52 +0100
      Re: Issuing a message in the language of the user "James Harris" <james.harris.1@gmail.com> - 2014-04-28 19:17 +0100
        Re: Issuing a message in the language of the user "BartC" <bc@freeuk.com> - 2014-04-29 22:17 +0100
          Re: Issuing a message in the language of the user "James Harris" <james.harris.1@gmail.com> - 2014-04-29 23:21 +0100
    Re: Issuing a message in the language of the user George Neuner <gneuner2@comcast.net> - 2014-04-28 12:27 -0400

#2031 — Issuing a message in the language of the user

I was going to add this to the existing thread about formatting numbers as 
it is related but it is really a topic in itself so am posting separately. I 
will focus on expressing this in C terms and will use C in the examples.

The idea is that a program wants to issue a message to a user (using a 
function which for the sake of giving it a name in this post I will call 
IssueMsg) but doesn't want to have to know what language the user speaks or 
what other locale settings are in effect. The message should appear in 
English to an English speaker, French to a French speaker etc. The IssueMsg 
routine is to look up the message in a library of the appropriate language 
for the user and then fill-in the parameter values supplied by the program.

This is akin to gettext() but, of course, much better. ;-)

Regarding the need for the order of values in a message to vary, a 
two-parameter message in English might have parm 1 first then parm 2 but the 
same message in French might be more naturally expressed by having parm 2 
come before parm 1. Rather than forcing the same order on all languages the 
message needs to pick the parameter for each location. This means that the 
message text cannot just use them in order but needs to have numbered or 
named parameters. Numbered is more efficient and was chosen for the 
suggestion below.

Therefore, to process the message there needs to be a table of parameters. A 
Posix extension to C's printf family apparently allows numbered parameters 
but I cannot see how that could be implemented easily using va_arg which is 
the only standard mechanism I am aware of in C for processing variable 
length argument lists.

So, rather than the normal printf form

  printf(message, parms);

the idea is for a program to send the message to a user by the following 
form of call

  IssueMsg(N, parms, message);

N would state how many parms there were. The parms would normally be pairs 
of

  "formatting code", value

but individual parms could be more complex if required as long as they were 
parseable.

The message would be something that could be looked up in a library for the 
current human language. The message text, regardless of human language, 
would refer to numbered parameters from the table. In other words IssueMsg 
would build the table first. Then it would scan the message substituting the 
arguments at the appropriate points.

In this way it would be easy, when processing the message, to refer back to 
numbered parameter entries in the table.

Having the number of table entries first would allow the table to be 
allocated in one go by the IssueMsg routine. It could be malloced or could 
even be put on the stack as long as each entry is of fixed size.

Where all this relates to the original thread is in the choice of 
"formatting code" elements. I won't bore you with what little I have done on 
that so far but it might be possible for both to use the same formatting 
code language.

James

[toc] | [next] | [standalone]

#2034

On Sun, 27 Apr 2014 20:29:42 +0100, James Harris wrote:

> The idea is that a program wants to issue a message to a user (using a 
> function which for the sake of giving it a name in this post I will call 
> IssueMsg) but doesn't want to have to know what language the user speaks or 
> what other locale settings are in effect. The message should appear in 
> English to an English speaker, French to a French speaker etc.

There is nothing worse than localized software. I never buy German Windows
or Visual Studio. Localization is a source of countless issues, e.g. the
notorious comma-or-point problem with Excel. IMO, localization contributed
to the fault of Algol 68. Russian Algol 68 report with translated keywords
was really pathetic. And the point is if user cannot understand or pay
attention to a message in English, he won't in whatever other language.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

[toc] | [prev] | [next] | [standalone]

#2035

On Sun, 27 Apr 2014 15:29:42 -0400, James Harris  
<james.harris.1@gmail.com> wrote:

> [snip]
>
> The idea is that a program wants to issue a message to a user
> (using a function which for the sake of giving it a name in this
> post I will call IssueMsg) but doesn't want to have to know what
> language the user speaks or what other locale settings are in
> effect. The message should appear in English to an English speaker,
> French to a French speaker etc. The IssueMsg routine is to look up
> the message in a library of the appropriate language for the user
> and then fill-in the parameter values supplied by the program.
>
> This is akin to gettext() but, of course, much better. ;-)
>
> Regarding the need for the order of values in a message to vary,
> a two-parameter message in English might have parm 1 first then
> parm 2 but the same message in French might be more naturally
> expressed by having parm 2 come before parm 1. Rather than
> forcing the same order on all languages the message needs to
> pick the parameter for each location. This means that the message
> text cannot just use them in order but needs to have numbered or
> named parameters. Numbered is more efficient and was chosen for
> the suggestion below.
>
> [snip]

Is there a reason each message needs to have values?

I.e., my inclination would be to have static strings for each
language selectable by index and pointer.  The pointer would
be set for the chosen language to select the appropriate array
of strings.  I would avoid emitting values, or I'd emit them on
a line without other text and without language specific formatting.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2039

"Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message 
news:op.xe0nt7y86zenlw@localhost...
> On Sun, 27 Apr 2014 15:29:42 -0400, James Harris 
> <james.harris.1@gmail.com> wrote:
>
>> [snip]
>>
>> The idea is that a program wants to issue a message to a user
>> (using a function which for the sake of giving it a name in this
>> post I will call IssueMsg) but doesn't want to have to know what
>> language the user speaks or what other locale settings are in
>> effect. The message should appear in English to an English speaker,
>> French to a French speaker etc. The IssueMsg routine is to look up
>> the message in a library of the appropriate language for the user
>> and then fill-in the parameter values supplied by the program.
>>
>> This is akin to gettext() but, of course, much better. ;-)
>>
>> Regarding the need for the order of values in a message to vary,
>> a two-parameter message in English might have parm 1 first then
>> parm 2 but the same message in French might be more naturally
>> expressed by having parm 2 come before parm 1. Rather than
>> forcing the same order on all languages the message needs to
>> pick the parameter for each location. This means that the message
>> text cannot just use them in order but needs to have numbered or
>> named parameters. Numbered is more efficient and was chosen for
>> the suggestion below.
>>
>> [snip]
>
> Is there a reason each message needs to have values?
>
> I.e., my inclination would be to have static strings for each
> language selectable by index and pointer.  The pointer would
> be set for the chosen language to select the appropriate array
> of strings.  I would avoid emitting values, or I'd emit them on
> a line without other text and without language specific formatting.

Some messages might not have values. They could be issued as normal but with 
no parameters. But some messages would need parameters. For example.

  your account balance is 10.62 CR
  you last logged in from IP address 10.1.1.4 on 5/5/2014
  syntax error on line 20 near column 8 expected one of ",", ";", "(".

James

[toc] | [prev] | [next] | [standalone]

#2041

"James Harris" <james.harris.1@gmail.com> wrote in message
news:ljm2c8$5tn$1@dont-email.me...
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message

>> Is there a reason each message needs to have values?

> Some messages might not have values. They could be issued as normal but
> with no parameters. But some messages would need parameters. For example.

You're not making it easy for yourself:

>  your account balance is 10.62 CR

Here you're dealing with local currency, and local conventions for
accounting, conversions and display which may vary anyway between different
kinds of applications even within the same region (with many having dual
currencies). (But this example only has one value so order doesn't matter,
if the '10.62 CR' forms a single item, the result of a separate currency
formatting option.)

>  you last logged in from IP address 10.1.1.4 on 5/5/2014

And here you have localisation of the date display.

>  syntax error on line 20 near column 8 expected one of ",", ";", "(".

Here however you might be able to simplify things by splitting things up, so
that the grammar of the language (if it even has such a thing) doesn't
matter so much:

  Syntax error:
    Line: 20
    Column: 8
    Expected: .....

There's even the option of using one format for English (like your example),
and something like the latter for a language it can't cope with so easily.
(I found that technical users at least, were often happy to use English.)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2049

On Mon, 28 Apr 2014 13:15:55 -0400, James Harris  
<james.harris.1@gmail.com> wrote:
> "Rod Pemberton" <dont_use_email@xnothavet.cqm> wrote in message
> news:op.xe0nt7y86zenlw@localhost...
>> On Sun, 27 Apr 2014 15:29:42 -0400, James Harris
>> <james.harris.1@gmail.com> wrote:

>>> [snip]
>>>
>>> The idea is that a program wants to issue a message to a user
>>> (using a function which for the sake of giving it a name in this
>>> post I will call IssueMsg) but doesn't want to have to know what
>>> language the user speaks or what other locale settings are in
>>> effect. The message should appear in English to an English speaker,
>>> French to a French speaker etc. The IssueMsg routine is to look up
>>> the message in a library of the appropriate language for the user
>>> and then fill-in the parameter values supplied by the program.
>>>
>>> This is akin to gettext() but, of course, much better. ;-)
>>>
>>> Regarding the need for the order of values in a message to vary,
>>> a two-parameter message in English might have parm 1 first then
>>> parm 2 but the same message in French might be more naturally
>>> expressed by having parm 2 come before parm 1. Rather than
>>> forcing the same order on all languages the message needs to
>>> pick the parameter for each location. This means that the message
>>> text cannot just use them in order but needs to have numbered or
>>> named parameters. Numbered is more efficient and was chosen for
>>> the suggestion below.
>>>
>>> [snip]
>>
>> Is there a reason each message needs to have values?
>>
>> I.e., my inclination would be to have static strings for each
>> language selectable by index and pointer.  The pointer would
>> be set for the chosen language to select the appropriate array
>> of strings.  I would avoid emitting values, or I'd emit them on
>> a line without other text and without language specific formatting.
>
> Some messages might not have values. They could be issued as normal but  
> with
> no parameters. But some messages would need parameters. For example.
>
>   your account balance is 10.62 CR
>   you last logged in from IP address 10.1.1.4 on 5/5/2014
>   syntax error on line 20 near column 8 expected one of ",", ";", "(".
>

I suspect you're going to end up with many large arrays of pointers to
functions.  One array set for each language with each array containing
function pointers for each type of formatting routine you need.  Set
the pointer to the appropriate array for the language, index, call
function pointer.  This generates messy code, but keeps all the
functions, or strings as mentioned earlier, under control, in one place.

The other option is to call one function for each formatting task,
so the code is clean, no indexing, no pointers, no calling function
pointers, etc.  But, then each format function needs to be "smart",
perhaps using a switch to select code for each language.


Rod Pemberton

[toc] | [prev] | [next] | [standalone]

#2036

"James Harris" <james.harris.1@gmail.com> wrote in message 
news:ljjlr6$4ok$1@dont-email.me...

> The idea is that a program wants to issue a message to a user (using a 
> function which for the sake of giving it a name in this post I will call 
> IssueMsg) but doesn't want to have to know what language the user speaks 
> or what other locale settings are in effect. The message should appear in 
> English to an English speaker, French to a French speaker etc.

I think to do the lookup, the program *will* have to know the locale (or at 
least, as I used to do it before OSes could deal with this properly), the 
language setting for this application. But also, the locale might say India, 
but the user would prefer English.

> So, rather than the normal printf form
>
>  printf(message, parms);
>
> the idea is for a program to send the message to a user by the following 
> form of call
>
>  IssueMsg(N, parms, message);
>
> N would state how many parms there were. The parms would normally be pairs 
> of
>
>  "formatting code", value
>
> but individual parms could be more complex if required as long as they 
> were parseable.
>
> The message would be something that could be looked up in a library for 
> the current human language.

(I wrote something about how I used to do such lookups in this stackexchange 
entry. Mine's about the third answer, posted by 'bartc': 
http://goo.gl/MRbROp)

> The message text, regardless of human language, would refer to numbered 
> parameters from the table.

So it would have embedded codes such as #3 or {3} to refer to a parameter 
number? (#3 will work for up to 9 parameters; having 362880 possible 
orderings ought to be sufficient.)

(BTW to be truly international it would have to work with Chinese, Urdu and 
Arabic for example; I wouldn't have a clue where to start with those. 
Remember also that the parameters themselves, if they contain strings, might 
also need translating.)

I suppose that is workable. Except I've worked with translations for (iirc) 
Dutch, German and French, and I don't recall this being much of an issue. 
(There were a few simple things such as plurals, but it was easier to write:

 (n=1|/"line"|/"lines"), and translate either "line" or "lines", than to 
use:  /"line"+(n=1|""|"s") which only worked for English.)

Do you have example messages where the ordering is that important, and where 
you can't write them using a fixed order? (Since these are computer 
messages, people will expect them to be a little cryptic; they don't need to 
be Shakespeare.)

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2042

"BartC" <bc@freeuk.com> wrote in message 
news:TGo7v.275119$Kx7.125128@fx26.am4...
> "James Harris" <james.harris.1@gmail.com> wrote in message 
> news:ljjlr6$4ok$1@dont-email.me...

...

>> The message text, regardless of human language, would refer to numbered 
>> parameters from the table.
>
> So it would have embedded codes such as #3 or {3} to refer to a parameter 
> number? (#3 will work for up to 9 parameters; having 362880 possible 
> orderings ought to be sufficient.)

I think there would need to be a beginning and ending delimiter. Using the 
codes we discussed in another thread, i.e. starting with a hash and ending 
with a dot the parameter position could be something like #3. to select 
parameter number 3.

More importantly, having a mandatory ending delimiter would allow other 
information elements to be included in the code. I am not sure that any 
would be, yet, but it seems likely. Perhaps things here could include left 
or right alignment, digit group separators, decimal point symbol etc. Not 
sure.

Your example of plurals, below, is better though. Having a beginning and an 
ending delimiter would allow for selections and other arbitrarily complex 
meanings to be encoded.

> (BTW to be truly international it would have to work with Chinese, Urdu 
> and Arabic for example; I wouldn't have a clue where to start with those. 
> Remember also that the parameters themselves, if they contain strings, 
> might also need translating.)

Yes.

> I suppose that is workable. Except I've worked with translations for 
> (iirc) Dutch, German and French, and I don't recall this being much of an 
> issue. (There were a few simple things such as plurals, but it was easier 
> to write:
>
> (n=1|/"line"|/"lines"), and translate either "line" or "lines", than to 
> use:  /"line"+(n=1|""|"s") which only worked for English.)

Plurals is an excellent issue. I suppose some languages may need different 
treatment for other numbers too. How about conditional selections in the 
message itself?

> Do you have example messages where the ordering is that important, and 
> where you can't write them using a fixed order? (Since these are computer 
> messages, people will expect them to be a little cryptic; they don't need 
> to be Shakespeare.)

I don't have any examples of messages where the order would vary but my 
knowledge of other languages is limited. It certainly seems possible, even 
likely, that the order would vary in at least some languages. If there was 
no selection by number then the translation into some languages could be 
forced to be awkward.

I wasn't thinking just of messages intended for the computer literate. For 
example, a web site could have lots to say to a user. The values could come 
from a database but still need to be written in the language of the person 
behind the web browser.

James

[toc] | [prev] | [next] | [standalone]

#2068

"James Harris" <james.harris.1@gmail.com> wrote in message 
news:ljm5v9$2p6$1@dont-email.me...
> "BartC" <bc@freeuk.com> wrote in message 
> news:TGo7v.275119$Kx7.125128@fx26.am4...

>> (n=1|/"line"|/"lines"), and translate either "line" or "lines", than to 
>> use:  /"line"+(n=1|""|"s") which only worked for English.)
>
> Plurals is an excellent issue. I suppose some languages may need different 
> treatment for other numbers too. How about conditional selections in the 
> message itself?
>
>> Do you have example messages where the ordering is that important, and 
>> where you can't write them using a fixed order? (Since these are computer 
>> messages, people will expect them to be a little cryptic; they don't need 
>> to be Shakespeare.)
>
> I don't have any examples of messages where the order would vary but my 
> knowledge of other languages is limited. It certainly seems possible, even 
> likely, that the order would vary in at least some languages. If there was 
> no selection by number then the translation into some languages could be 
> forced to be awkward.
>
> I wasn't thinking just of messages intended for the computer literate. For 
> example, a web site could have lots to say to a user. The values could 
> come from a database but still need to be written in the language of the 
> person behind the web browser.

I think this is starting to be more the responsibility of the application 
rather than the language, which perhaps can just concern itself with the 
practicalities of dealing with out-of-order print items.

I also think that when there is a lot of user interaction, then a scripting 
language should be involved, on top of the main application language if 
necessary. It doesn't need to be very fast. Then it might be that the easy 
ability to deal with strings and lists and dictionaries and lookups, can 
trivialise the task of assembling a message.

So your example from elsewhere:   "syntax error on line 20 near column 8 
expected one of "","", "";"", ""("".", might appear in the source as "syntax 
error on line {lineno} near column {columnno} expected one of {itemlist}". 
The names in braces refer directly to a relevant variable or possibly an 
expression. After translation, the {...} items are preserved, but might be 
in a different order. (Or a little simpler, still use {1} {2} {3}, in 
association with a separate list of string values.)

But now it is just text processing, it needn't be much to do with printing 
at all (other than for the final result).

-- 
Bartc 

[toc] | [prev] | [next] | [standalone]

#2069

"BartC" <bc@freeuk.com> wrote in message 
news:GGU7v.217921$te5.88629@fx13.am4...
> "James Harris" <james.harris.1@gmail.com> wrote in message 
> news:ljm5v9$2p6$1@dont-email.me...
>> "BartC" <bc@freeuk.com> wrote in message 
>> news:TGo7v.275119$Kx7.125128@fx26.am4...
>
>>> (n=1|/"line"|/"lines"), and translate either "line" or "lines", than to 
>>> use:  /"line"+(n=1|""|"s") which only worked for English.)
>>
>> Plurals is an excellent issue. I suppose some languages may need 
>> different treatment for other numbers too. How about conditional 
>> selections in the message itself?
>>
>>> Do you have example messages where the ordering is that important, and 
>>> where you can't write them using a fixed order? (Since these are 
>>> computer messages, people will expect them to be a little cryptic; they 
>>> don't need to be Shakespeare.)
>>
>> I don't have any examples of messages where the order would vary but my 
>> knowledge of other languages is limited. It certainly seems possible, 
>> even likely, that the order would vary in at least some languages. If 
>> there was no selection by number then the translation into some languages 
>> could be forced to be awkward.
>>
>> I wasn't thinking just of messages intended for the computer literate. 
>> For example, a web site could have lots to say to a user. The values 
>> could come from a database but still need to be written in the language 
>> of the person behind the web browser.
>
> I think this is starting to be more the responsibility of the application 
> rather than the language, which perhaps can just concern itself with the 
> practicalities of dealing with out-of-order print items.

Yes, this is not a language issue. The suggested approach was intended to be 
something that could be part of a library and could be used in any language.

> I also think that when there is a lot of user interaction, then a 
> scripting language should be involved, on top of the main application 
> language if necessary. It doesn't need to be very fast. Then it might be 
> that the easy ability to deal with strings and lists and dictionaries and 
> lookups, can trivialise the task of assembling a message.
>
> So your example from elsewhere:   "syntax error on line 20 near column 8 
> expected one of "","", "";"", ""("".", might appear in the source as 
> "syntax error on line {lineno} near column {columnno} expected one of 
> {itemlist}". The names in braces refer directly to a relevant variable or 
> possibly an expression. After translation, the {...} items are preserved, 
> but might be in a different order. (Or a little simpler, still use {1} {2} 
> {3}, in association with a separate list of string values.)

IMO allowing the message to include variable names would be a bad idea 
because it suggests that arbitrary variables could be printed thus damaging 
security, and in a compiled language it would require the executable to be 
aware of where each name is stored. A dictionary of terms could be built, 
however, and the message could then use names from that dictionary. But 
numbers would be faster and simpler, even if not so user-friendly.

James

[toc] | [prev] | [next] | [standalone]

#2038

On Sun, 27 Apr 2014 20:29:42 +0100, "James Harris"
<james.harris.1@gmail.com> wrote:

>The idea is that a program wants to issue a message to a user (using a 
>function which for the sake of giving it a name in this post I will call 
>IssueMsg) but doesn't want to have to know what language the user speaks or 
>what other locale settings are in effect. The message should appear in 
>English to an English speaker, French to a French speaker etc. 

One of the biggest problems with localization is crafting a
*meaningful* message in every supported language.  The length of a
message can vary greatly: what is a relatively brief message in
English - a phrase or a sentence - can easily turn into a sizable
paragraph in some languages. 
[I presume the reverse can happen also but I've never seen it.  IME
the English version almost always is the shortest.]

I'm for localization, but against localization done poorly. IMO, if
you can't make it look and feel native in every supported language,
it's best not to bother because you'll only alienate users.  In the
general case making something feel right in multiple languages is a
lot harder than simply translating text.

YMMV
George

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.misc

csiph-web