Opened 10 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 )
XMPP lobby subject should be translated for i18n. (and also implemented).
Change History (15)
comment:1 by , 10 years ago
Description: | modified (diff) |
---|
comment:3 by , 10 years ago
Milestone: | Alpha 16 → Alpha 17 |
---|---|
Type: | defect → enhancement |
Since we are already in string and feature freeze, I'm pushing this.
comment:4 by , 10 years ago
Milestone: | Alpha 17 → Alpha 18 |
---|
comment:5 by , 10 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 , 9 years ago
Milestone: | Alpha 18 → Backlog |
---|
comment:8 by , 5 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 https://developer.pidgin.im/ticket/6267) 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 lobby.wildfiregames.com/0ad' from='arena24 conference.lobby.wildfiregames.com/elexis' 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 http://www.i18nguy.com/unicode/language-identifiers.html
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 , 5 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 , 3 years ago
Milestone: | Backlog → Alpha 25 |
---|
Hopefully can be fixed with A25 along with the other issues.
follow-up: 15 comment:11 by , 3 years 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 , 3 years ago
Milestone: | Alpha 25 → Alpha 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 , 2 years ago
Milestone: | Alpha 26 → Alpha 27 |
---|
comment:15 by , 3 weeks ago
I agree with wraitii here and believe the downsides outweigh the benefits.
While XEP-0171 is stable nowadays, it doesn't apply to MUC room subjects and is neither supported by ejabberd nor by most XMPP clients. Supporting translated subjects would therefore require a proprietary pyrogenesis-only solution, making it impossible to use this functionality with other XMPP clients.
Aside from that for every change of the lobby subject the one changing it would need to get proper translations first, which is simply too time consuming for quick changes.
All of that would be for a lobby, where communication is supposed to happen in English only anyway.
Therefore, I propose to close this issue as wontfix.
Maybe it'd make sense to include that "communication in English only" in the Terms of Service to have that written down somewhere.
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.
Current:
Proposed: