Opened 9 years ago

Last modified 3 weeks ago

#2489 new enhancement

Lobby subject should be translated.

Reported by: scythetwirler Owned by:
Priority: Must Have Milestone: Backlog
Component: Multiplayer lobby Keywords:
Cc: Patch:

Description (last modified by scythetwirler)

XMPP lobby subject should be translated for i18n. (and also implemented).

Change History (14)

comment:1 by scythetwirler, 9 years ago

Description: modified (diff)

comment:2 by Josh, 9 years ago

The ideal solution would be with XEP-0171: Language Translation. But that is only a draft and none of our libraries say they support it yet. A possible stop-gap would be somehow implementing the part of XEP-0171 concerning subjects on top of current implementations.


  <subject>Welcome to the 0 A.D. lobby!</subject>


  <subject xml:lang='en'>Welcome to the 0 A.D. lobby!</subject>
  <subject xml:lang='fr'>Bienvenue dans le hall de 0 A.D.!</subject>
  <subject xml:lang='nl'>Welkom op de 0 A.D. lobby!</subject>
  <subject xml:lang='de'>Willkommen auf der 0 A.D. Lobby!</subject>
  <subject xml:lang='zh'>欢迎您到公元0大堂!</subject>
Last edited 9 years ago by Josh (previous) (diff)

comment:3 by scythetwirler, 9 years ago

Milestone: Alpha 16Alpha 17
Type: defectenhancement

Since we are already in string and feature freeze, I'm pushing this.

comment:4 by Itms, 8 years ago

Milestone: Alpha 17Alpha 18

in reply to:  2 comment:5 by historic_bruno, 8 years ago

Replying to Josh:

The ideal solution would be with XEP-0171: Language Translation. But that is only a draft and none of our libraries say they support it yet. A possible stop-gap would be somehow implementing the part of XEP-0171 concerning subjects on top of current implementations.

Is that really ideal considering our current translation system, the translation would be performed by the server? I would expect it to be translated by the engine, on display, like the rest of the game's strings.

Apparently the subject is currently stored on the server, so it's not easy to integrate with the Transifex-based system we're using (see Internationalization_and_Localization).

comment:6 by leper, 8 years ago

Milestone: Alpha 18Backlog

comment:7 by Stan`, 7 years ago

Owner: Josh removed

Unassigning due to lack of activity.

comment:8 by elexis, 3 years ago

The string can't be committed to the codebase, otherwise you can change it once per release. And then that's not the actuall XMPP room subject anymore either, since it's a different datasource. (If the string is committed to the repository, how is it different from just being a regular GUI text hint? misleading to call it subject then.)

In psi+ one can set the lobby subject in multiple languages, so that should be the data source too. (In pidgin one can't even set the subject If one does so, 0ad doesn't display the english language one, so one shouldn't use that as of r22899.

gloox supports obtaining subject and body of a chat message in different languages:

The language identifier for the desired language. It must conform to section 2.12 of the XML specification and RFC 3066. If empty, the default body will be returned, if any.

(But that's not the lobby subject it seems)

So the moderator XMPP client supports it, the ejabberd server supports it, our code can be changed to support it, only remaining question is whether gloox supports it.

This is what the server sends (captured with wireshark, @ symbol removed):

<message xml:lang='en' to='elexis3' from='arena24' type='groupchat' id='aaeba'><subject>(english subject...)</subject><subject xml:lang='de'>(german subject...)</subject></message>

This message however arrives under handleMUCSubject at XmppClient, from handleMUCSubject from glooxwrapper, from handleMUCSubject from gloox, from MUCRoom::handleMessage in gloox mucroom.cpp.

So that is

Since the gloox subject() function does provide a language argument, it seems one should be able to do something about it - in gloox.

comment:9 by elexis, 3 years ago

gloox stanza.h has getLangs, that could be added to message.h and read the language keys from its m_subjects and m_bodies.

The handleMUCSubject function would have to be changed to pass the complete message pointer instead of a subject string.

Then the glooxwrapper::Message could expose that getLangs function to that glooxwrapper::Message argument of XmppClient::handleMUCSubject.

One might then pass all languages to the JS GUI message (r22856) and for example provide a dropdown for the language selection of the subject. Alternatively one can filter in C++ for either the selected or fallback default language.

Obtaining the subject in different languages doesn't seem possible via the MUCRoom, see MUCRoomHandler from gloox mucroomhandler.h.

comment:10 by Stan`, 2 years ago

Milestone: BacklogAlpha 25

Hopefully can be fixed with A25 along with the other issues.

comment:11 by wraitii, 21 months ago

To an extent I disagree with the premise here. The lobby is English language, and I don't see much point in translating bits of it. Further, and as noted above, it's quite complex. IMO, we just shouldn't bother. If some translation is wanted (such as 'The lobby is in English language'), we should hardcode that into 0 A.D. itself.

comment:12 by Stan`, 20 months ago

Milestone: Alpha 25Alpha 26

Couldn't the user send a request to the server with his prefered language? and have a Transifex resource for that?

comment:13 by Freagarach, 10 months ago

Milestone: Alpha 26Alpha 27

comment:14 by Freagarach, 3 weeks ago

Milestone: Alpha 27Backlog

Pushing back.

Note: See TracTickets for help on using tickets.