Simplification of localization.

classic Classic list List threaded Threaded
16 messages Options
-
Reply | Threaded
Open this post in threaded view
|

Simplification of localization.

-
Dear Lua developers.
Please move all message strings to one header file.
It greatly simplifies the localization of a Lua engine.



Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Dirk Laurie-2
You mean something like this:

error(msg.x_should_lie_between_0_and_255)

instead of

error("x should lie between 0 and 255")

with

msg = require "russian_messages"

or whatever earlier?


2014-10-29 7:51 GMT+02:00 - <[hidden email]>:
> Dear Lua developers.
> Please move all message strings to one header file.
> It greatly simplifies the localization of a Lua engine.
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

steve donovan
On Wed, Oct 29, 2014 at 8:01 AM, Dirk Laurie <[hidden email]> wrote:
> You mean something like this:
>
> error(msg.x_should_lie_between_0_and_255)

Although I think the OP means in the Lua core, so it's more like

#define x_should_lie_between_0_and_25 "x should lie between 0 and 255"

Tricky to do when there's format specifiers in general.

Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Philipp Janda
Am 29.10.2014 um 07:11 schröbte steve donovan:

> On Wed, Oct 29, 2014 at 8:01 AM, Dirk Laurie <[hidden email]> wrote:
>> You mean something like this:
>>
>> error(msg.x_should_lie_between_0_and_255)
>
> Although I think the OP means in the Lua core, so it's more like
>
> #define x_should_lie_between_0_and_25 "x should lie between 0 and 255"
>
> Tricky to do when there's format specifiers in general.

We probably need a way to specify the order in format specifiers (like
in GLIBC) first ...

 From `man 3 printf`:

> Many  countries  use the day-month-year order.  Hence, an internationalized version must be able to print the arguments in an
>        order specified by the format:
>
>            #include <stdio.h>
>            fprintf(stdout, format,
>                    weekday, month, day, hour, min);
>
>        where format depends on locale, and may permute the arguments.  With the value:
>
>            "%1$s, %3$d. %2$s, %4$d:%5$.2d\n"
>
>        one might obtain "Sonntag, 3. Juli, 10:02".


Philipp



Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Roberto Ierusalimschy
> >Tricky to do when there's format specifiers in general.
>
> We probably need a way to specify the order in format specifiers
> (like in GLIBC) first ...

We probably need more than that. Many error messages in Lua are built
piece by piece, not in a single format string. For instance, consider
this message:

  > a = a + 1
  stdin:1: attempt to perform arithmetic on a table value (global 'a')

Thre is "attempt to %s a %s value%s", then an optional " (%s '%s')",
filled with "perform arithmetic on", "table", "global", and 'a'. (BTW,
"table" here is the type buildin name; should it be translated too?)
You have to make sure the individual translation of each of these parts
will bring good results, considering all places each of these parts can
go. (Note that we are lucky that all buildin type names in Lua work
with article "a" (as oposed to "an"); we may not be that lucky in
other languages...)

-- Roberto

Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Michal Kolodziejczyk-3


On 29.10.2014 13:32, Roberto Ierusalimschy wrote:
>>> Tricky to do when there's format specifiers in general.
>>
>> We probably need a way to specify the order in format specifiers
>> (like in GLIBC) first ...
>
> We probably need more than that. Many error messages in Lua are built
> piece by piece, not in a single format string. For instance, consider
> this message:

I think (read: am afraid) that many tools depend on exact error message
format. OTOH, if I used lua, I would want to be able to parse error
messages independent on user locale, i.e. don't want user's locale
setting to mess with error messages of the interpreter.

The solution(?) would be to use "error objects" - each error message
(object/structure) would have its unique errorId, and optional
parameters. Then render those messages at the highest possible level,
possibly using default lua renderer and a map of errorId to
errorMessages. But it seems like a lot of work.

>   > a = a + 1
>   stdin:1: attempt to perform arithmetic on a table value (global 'a')
>
> Thre is "attempt to %s a %s value%s", then an optional " (%s '%s')",
> filled with "perform arithmetic on", "table", "global", and 'a'. (BTW,
> "table" here is the type buildin name; should it be translated too?)

IMO no, because then you would need to translate some/all lua commands
and/or parameters (type({})=="table").

Regards,
miko

Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Javier Guerra Giraldez
In reply to this post by -
On Wed, Oct 29, 2014 at 12:51 AM, - <[hidden email]> wrote:
> Please move all message strings to one header file.
> It greatly simplifies the localization of a Lua engine.


I think this is a bad idea in itself.  any message generated by the
engine itself should be considered part of the implementation, not to
be shown to a user.

most people would agree that it would be foolish to translate the
language keywords (i wouldn't like to write "si calza(cadena, patrón)
entonces imprimir ('de acuerdo') fin" instead of "if match(string,
pattern) then print ('OK') end" ).  What about the names of the value
types? ("number", "table", etc), or the library function names?  as
noted by Roberto and Michal, some messages use those names as part of
the text.

As long as the language (and libraries) allow you to write your
programs that interact with the user in any language you care about,
then there's no need for further "localization" of the engine.

--
Javier

Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Enrico Colombini
In reply to this post by Michal Kolodziejczyk-3
On 29/10/2014 14.57, Michal Kolodziejczyk wrote:

> I think (read: am afraid) that many tools depend on exact error message
> format. OTOH, if I used lua, I would want to be able to parse error
> messages independent on user locale, i.e. don't want user's locale
> setting to mess with error messages of the interpreter.
>
> The solution(?) would be to use "error objects" - each error message
> (object/structure) would have its unique errorId, and optional
> parameters. Then render those messages at the highest possible level,
> possibly using default lua renderer and a map of errorId to
> errorMessages. But it seems like a lot of work.

That would be a sensible (if possibly costly) solution. I encountered
more than once, while designing user-oriented DSLs, the need to catch a
Lua error and display meaningful information about it.
Catching the error is easy (just use pcall), decoding and/or re-encoding
the error message in a user-suitable way (even in English!) is not. I do
not think that parsing error messages, relying on exact wording, would
be a good idea.

That's why some time ago I proposed the (very partial) low cost
'solution' of prepending an unique code to error messages, e.g.:

   a.lua:23: [e123] attempting to index a nil value (global 'x')

It would be easy to identify the error type (file and line are already
there), though any extra information (such as 'x') would be lost.
Efficient but sadly incomplete.
I am sure the Lua developers can thing of an efficient *and* effective
way :-)

For my own code I just use error() statements and catch them with pcall.
However, this does not solve the problem of reporting errors inside user
chunks in a user-friendly (and DSL-related) way.

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Dirk Laurie-2
In reply to this post by steve donovan
2014-10-29 8:11 GMT+02:00 steve donovan <[hidden email]>:
> On Wed, Oct 29, 2014 at 8:01 AM, Dirk Laurie <[hidden email]> wrote:
>> You mean something like this:
>>
>> error(msg.x_should_lie_between_0_and_255)
>
> Although I think the OP means in the Lua core,

In that case my innate reticence and politeness bars me from
formulating in a public forum what I think of the notion.

Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Jorge Visca
In reply to this post by Javier Guerra Giraldez
Once upon a time Visual Basic for Applications in Microsoft Office
applications were localized. So, a macro for your spanish Excel had to
be written in spanish, as in your examples ("si... entonces...").
Aaaaaaand error messages were so horribly worded and
other-guy-in-internet-with-the-same-problem impaired as to be useless.

It was Hell.

Jorge

On 10/29/2014 12:11 PM, Javier Guerra Giraldez wrote:

> On Wed, Oct 29, 2014 at 12:51 AM, - <[hidden email]> wrote:
>> Please move all message strings to one header file.
>> It greatly simplifies the localization of a Lua engine.
>
>
> I think this is a bad idea in itself.  any message generated by the
> engine itself should be considered part of the implementation, not to
> be shown to a user.
>
> most people would agree that it would be foolish to translate the
> language keywords (i wouldn't like to write "si calza(cadena, patrón)
> entonces imprimir ('de acuerdo') fin" instead of "if match(string,
> pattern) then print ('OK') end" ).  What about the names of the value
> types? ("number", "table", etc), or the library function names?  as
> noted by Roberto and Michal, some messages use those names as part of
> the text.
>
> As long as the language (and libraries) allow you to write your
> programs that interact with the user in any language you care about,
> then there's no need for further "localization" of the engine.
>


Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Lorenzo Donati-3
In reply to this post by Javier Guerra Giraldez


On 29/10/2014 15:11, Javier Guerra Giraldez wrote:
> On Wed, Oct 29, 2014 at 12:51 AM, - <[hidden email]> wrote:
>> Please move all message strings to one header file.
>> It greatly simplifies the localization of a Lua engine.
>
>
> I think this is a bad idea in itself.  any message generated by the
> engine itself should be considered part of the implementation, not to
> be shown to a user.
>
I strongly agree!

> most people would agree that it would be foolish to translate the
> language keywords (i wouldn't like to write "si calza(cadena, patrón)
> entonces imprimir ('de acuerdo') fin" instead of "if match(string,
> pattern) then print ('OK') end" ).  What about the names of the value
> types? ("number", "table", etc), or the library function names?  as
> noted by Roberto and Michal, some messages use those names as part of
> the text.
>

Yep! And someone thought it was a good idea in some other context:
spreadsheets applications usually change the built-in function names
according to locale settings!

> As long as the language (and libraries) allow you to write your
> programs that interact with the user in any language you care about,
> then there's no need for further "localization" of the engine.
>
+1

Cheers!

-- Lorenzo

--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments


Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Lorenzo Donati-3
In reply to this post by Jorge Visca


On 31/10/2014 20:41, Jorge wrote:
> Once upon a time Visual Basic for Applications in Microsoft Office
> applications were localized. So, a macro for your spanish Excel had to
> be written in spanish, as in your examples ("si... entonces...").
> Aaaaaaand error messages were so horribly worded and
> other-guy-in-internet-with-the-same-problem impaired as to be useless.

You were faster than me! :-)

I was just thinking of the same issue, but I wasn't sure I remembered
correctly (I stopped using MS office in favor of Open/LibreOffice almost
a decade ago!), but I seem to remember the same issue for
plain spreadsheet's function names.

Were the function names used to be saved in the file itself? IIRC
sometimes I've received an Excel file with all the function names borked
(not sure of the cause, but I don't think it was a simple locale setting
issue on
my machine).

> It was Hell.
>
Yep!

> Jorge


--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Enrico Colombini
In reply to this post by Lorenzo Donati-3
On 01/11/2014 11.39, Lorenzo Donati wrote:
>> I think this is a bad idea in itself.  any message generated by the
>> engine itself should be considered part of the implementation, not to
>> be shown to a user.
>
> I strongly agree!

I think most of us agree on that. What I would like to have is a way to
identify an error made by an user within a Lua-base domain-specific
language, so that I could show an appropriate message
(where "appropriate" could mean application-related, simplified and/or
translated).

Currently the information available from pcall() and (indirectly) from
xpcall() is the default "error object", which is a string.
File name and line number are easily parsed from that string, error type
and parameters are not.

Maybe I am just missing something obvious. How do Lua-scriptable games
handle error feedback in user scripts?

--
   Enrico

Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Choonster TheMage


On 1 November 2014 22:36, Enrico Colombini <[hidden email]> wrote:
Maybe I am just missing something obvious. How do Lua-scriptable games handle error feedback in user scripts?

--
  Enrico


Word of Warcraft just shows a popup with the text of the error when an error is thrown. It doesn't try to localise or simplify the error.
Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Lorenzo Donati-3
In reply to this post by Enrico Colombini


On 01/11/2014 12:36, Enrico Colombini wrote:

> On 01/11/2014 11.39, Lorenzo Donati wrote:
>>> I think this is a bad idea in itself.  any message generated by the
>>> engine itself should be considered part of the implementation, not to
>>> be shown to a user.
>>
>> I strongly agree!
>
> I think most of us agree on that. What I would like to have is a way to
> identify an error made by an user within a Lua-base domain-specific
> language, so that I could show an appropriate message
> (where "appropriate" could mean application-related, simplified and/or
> translated).
>
> Currently the information available from pcall() and (indirectly) from
> xpcall() is the default "error object", which is a string.
> File name and line number are easily parsed from that string, error type
> and parameters are not.
>
Yes, I agree that error management "overriding" is not easy in Lua.
Extracting information from errors coming from "lower level" layers of
an application is hard. It would be nice if the basic Lua error object
were a table populated with some useful fields and a __tostring
metamethod, so that one could say, for example, errobj.line,
errobj.message, etc., and still be able to print the error easily.


Alas, I fear that this would entail a radical overhaul of Lua codebase:
If I understood correctly what Roberto said, all errors are strings
built piecewise in different locations, with no "centralized" error
management or formatting routine.

Even if feasible, then there is the "fat penalty". How much fat could
Lua implementation take if the error building mechanisms were changed
like that? Maybe with Lua incorporating utf8 this would be an useful
addition and worth some "fat". Maybe it could even be a chance to
tidy things up? I don't know Lua codebase so well, but if error
generation is scattered throughout the code, maybe a reorganization of
the whole mechanism could even make Lua lose some weight. Really I don't
know.

I'm curious about what's the Lua team's mind about that.

Cheers!

-- Lorenzo

--
()  ascii ribbon campaign - against html e-mail
/\  www.asciiribbon.org   - against proprietary attachments

Reply | Threaded
Open this post in threaded view
|

Re: Simplification of localization.

Jorge Visca
In reply to this post by Lorenzo Donati-3
On 11/01/2014 08:56 AM, Lorenzo Donati wrote:
> I was just thinking of the same issue, but I wasn't sure I remembered
> correctly (I stopped using MS office in favor of Open/LibreOffice almost
> a decade ago!), but I seem to remember the same issue for
> plain spreadsheet's function names.

Now that you mention it, yeah, i think plain functions were localized
too... It was Office 97, 2000 tops, details are murky :)

> Were the function names used to be saved in the file itself? IIRC
> sometimes I've received an Excel file with all the function names borked
> (not sure of the cause, but I don't think it was a simple locale setting
> issue on
> my machine).

As I remember it, it wasn't the locale of the machine, but the localized
version of the Office package you had installed. There were different
versions for different languages, and the macros written in one could
not be run in another.


Jorge