On Tue, 2007-07-17 at 21:49 +1200, Lee Begg wrote:
> Hi all.
>
> I18n and L10n, fun.
I think it's something we really need to figure out.
> > There are really two parts to doing this,
> > - Client internationalisation
> > - Server messages internationalisation
> >
> > The first part should be mostly solved by using what ever preferred
> > method is for your programming language (IE Gettext or similar).
>
> Yes. Clients *SHOULD* do this already. If not, you should at least think
> about
> it.
tpclient-pywx use too, but I got lazy and nobody was translating the
client anyway.
> > The second is a little more tricky. As messages are unique to the
> > servers, they need a way to provide different languages to the client.
>
> Not just unique to the server, unique to the ruleset.
True.
> > Servers should be able to advertise the languages they support and the
> > client needs to have a way to tell the server to use a language.
>
> Yes. The bottleneck (the most limited choice) of languages will most probably
> be the rulesets.
Yes agreed.
> > I was
> > thinking that something like using the same framework as the "filters"
> > might work?
>
> Well..... filters are applied on a per-connection basis. EOT happens without
> having connections, and EOT processing needs to know the languages to use for
> messages, etc. So I don't think using the filters will work. It needs to be
> associated with the player directly.
I was thinking that the translation could occur "on the fly". This would
make storing messages on the server a little bit harder, but it should
be dooable. The server is really only going to have to localize the
message body as the arguments are going to be names of things (and thus
not need translation).
Here is how I was thinking that it could work on the server. The server
stores the unparsed "message string", plus the arguments to be put into
the message. IE If you used something like a printf method, you would
store, printf(<message>, <arguments>). Then before returning the message
you run it through the localizer, then insert the arguments. Something
like printf(gettext.localize(<message>), <arguments>).
See this example, say you had a message which read, "You ship %s was
destroyed." and you wanted to say "Ship 1" was destoryed. You would
store ("Your ship %s was destroyed.", "Ship 1"). Then when sending out
the message in say Spanish, the message is converted to "Tu nave %s fue
destruida." and then insert "Ship 1" into the message.
It would also allow two players of different languages to share an
account.
I'm not sure if I like this method or not, it would be trivial for me to
implement in tpserver-py, but it might be much harder to tpserver-cpp.
> > What do others think?
>
> Another issue is how will players using different languages communicate? In
> particular for diplomacy, etc. I note that the same issue also applies to AI
> clients.
I don't think that is a huge problem, not one I think we really need to
solve. Most players will be able to communicate via common languages and
other tools, they would be more comfortable however using tools in their
native language.
Of course some type of "trade method" which could be easily translated
might be useful, but outside the scope of this discussion.
Mithro
_______________________________________________
tp-devel mailing list
[email protected]
http://www.thousandparsec.net/tp/mailman.php/listinfo/tp-devel
