International support in Lua

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

International support in Lua

Nick Gammon
Hello everyone,

I have scanned the list and Googled for an answer without heaps of success so please bear with me if this has been asked before recently.

I am in the process of adding Internationalization (i18n) to my application, and been investigating gettext and other methods of translating strings.

Having had modest success with my main program, I am now turning my attention to Lua as my app uses it for scripting.

As far as I can see, there is no provision for making Lua more gettext-friendly. Thus, I make the following suggestion:

For error messages (in particular) which are currently in English, it would be helpful if the developers could surround them by a simple macro, which could aid production of a gettext translation template.

For example, instead of:

  luaL_error(L, "invalid format (repeated flags)");

... you would have:

  luaL_error(L, _TR("invalid format (repeated flags)"));

The exact name of the macro isn't important. In the include file you can then declare:

#define _TR(string) (string)

Thus effectively, from Lua's point of view, this becomes a no-op, which does not alter or slow down execution in any way.

However then you can do a "pass" over the source using xgettext, and extract out all the error messages into a translation template file. This could be used to automatically translate the errors from one language to another. For example, an implementor might change _TR to actually do the translation when required.

There are some issues, such as formatted error strings, and the fairly extensive use of the LUA_QL macro, however these could be overcome.

Are there any major objections? Do all Lua developers use English? Or would it be helpful?

Regards,

- Nick Gammon

Reply | Threaded
Open this post in threaded view
|

RE: International support in Lua

Patrick Donnelly-2
I think you could solve your problem in one of two ways. One of which was adopted (and probably not for the first time) by World of Warcraft. Make a couple files, each for their respective nationality, and fill them with global strings. You can probably make some function if not in Lua then in C (I assume you are using) that will get the location of the user of your program. Simply at the top of the chunk (the file) put:

First file:

    if not GetLocation = "X" then return end;

    ERROR1 = "Attempt to index a nil value";

Second file:

    if not GetLocation = "Y" then return end;

    ERROR1 = "Attempt to index a nil value"; --In Y language

Further, if you don't like filling the Global environment with variables containing localized strings, you can put them inside a table very easily. If you don't understand how to do that read up on modules in PIL.

Your other option, which I'm pretty sure you can do, is have C push these strings onto the global environment manually. I'm not sure on the specifics for that and will either let you research that or let someone else elaborate.

Hope that helps,

-Patrick Donnelly

"One of the lessons of history is that nothing is often a good thing to do and always a clever thing to say."

-Will Durant


> To: [hidden email]

> From: [hidden email]
> Subject: International support in Lua
> Date: Thu, 14 Jun 2007 09:50:32 +1000
>
> Hello everyone,
>
> I have scanned the list and Googled for an answer without heaps of
> success so please bear with me if this has been asked before recently.
>
> I am in the process of adding Internationalization (i18n) to my
> application, and been investigating gettext and other methods of
> translating strings.
>
> Having had modest success with my main program, I am now turning my
> attention to Lua as my app uses it for scripting.
>
> As far as I can see, there is no provision for making Lua more
> gettext-friendly. Thus, I make the following suggestion:
>
> For error messages (in particular) which are currently in English, it
> would be helpful if the developers could surround them by a simple
> macro, which could aid production of a gettext translation template.
>
> For example, instead of:
>
> luaL_error(L, "invalid format (repeated flags)");
>
> ... you would have:
>
> luaL_error(L, _TR("invalid format (repeated flags)"));
>
> The exact name of the macro isn't important. In the include file you
> can then declare:
>
> #define _TR(string) (string)
>
> Thus effectively, from Lua's point of view, this becomes a no-op,
> which does not alter or slow down execution in any way.
>
> However then you can do a "pass" over the source using xgettext, and
> extract out all the error messages into a translation template file.
> This could be used to automatically translate the errors from one
> language to another. For example, an implementor might change _TR to
> actually do the translation when required.
>
> There are some issues, such as formatted error strings, and the
> fairly extensive use of the LUA_QL macro, however these could be
> overcome.
>
> Are there any major objections? Do all Lua developers use English? Or
> would it be helpful?
>
> Regards,
>
> - Nick Gammon
Reply | Threaded
Open this post in threaded view
|

RE: International support in Lua

Tony Finch
On Wed, 13 Jun 2007, Patrick Donnelly wrote:

> Make a couple files, each for their respective nationality, and fill
> them with global strings. You can probably make some function if not in
> Lua then in C (I assume you are using) that will get the location of the
> user of your program. Simply at the top of the chunk (the file)
> put:First file:  if not GetLocation = "X" then return end;  ERROR1 =
> "Attempt to index a nil value";Second file:  if not GetLocation = "Y"
> then return end; ERROR1 = "Attempt to index a nil value"; --In Y language

Gnu gettext does exactly this. What the original poster is asking for is
to have hooks in the Lua core that support this functionality.

Tony.
-- 
f.a.n.finch  <[hidden email]>  http://dotat.at/
SOUTH FITZROY: SOUTHWEST VEERING WEST 5 TO 7, PERHAPS GALE 8 LATER. MODERATE
OR ROUGH, OCCASIONALLY VERY ROUGH LATER. RAIN OR SHOWERS. MODERATE OR GOOD.