-
-
Notifications
You must be signed in to change notification settings - Fork 91
Translation
Every string (bit of text) in the application is defined and described in client/src/elm/MassiveDecks/Strings.elm
. Translating the application involves providing a translated version of each string.
Note the difference between "Players" and "Users". Players play the game, users includes both players and spectators, and is the more general term.
In the code, there is a strict distinction between a "Game" (a single game of MD) and a "Lobby" (a room in which players congregate to play one of more games). In the application, we refer to them both as a "game"—it is simpler and users don't really care about the subtle difference in the concepts.
A play code is a Cardcast-specific thing that specifies a deck on their platform, and is not the same thing as a game code, which allows a user to join a game in Massive Decks.
Please use unicode characters as appropriate. E.g: the em-dash (—) (which is particularly awkward to notice in monospaced fonts, real quotes (“”), apostrophes (’) and ellipsis (…).
Likewise, unicode offers us valuable hinting tools to control hyphenation and line breaking:
- A unicode soft hyphen (
\u{00AD}
) indicated a good point in a word to break it if needed. - A unicode zero-width space (
\u{200B}
) can do the same thing without a hyphen (hyphens should be preferred, however, assuming that is true for the language generally). - For the reverse (no line breaking between words), use a unicode non-breaking space (
\u{00A0}
).
Before getting to deep into the details: adding the translation to the game itself is somewhat technical. If you struggle with it, please feel free to make a bug and get a developer to help you—you can do the translation itself more simply and a developer can do the work of adding the translation, and skip this section.
The best way to get started is to copy the client/src/MassiveDecks/Languages/En.elm
translation. Add the language to the lists in both client/src/MassiveDecks/Languages/Model.elm
and client/src/MassiveDecks/Languages.elm
(at the top and at the bottom in pack
).
e.g: Adding English (Great Britain). The IETF language tag for this is en-GB
, so we'll use EnGB
as the name.
In client/src/MassiveDecks/Languages/Model.elm
:
type Language
= En
...
| EnGB -- Add this line.
In client/src/MassiveDecks/Languages.elm
:
languages : List Language
languages =
[ En
...
, EnGB -- Add this line.
]
...
pack : Language -> Translation.Pack
pack language =
case language of
En ->
EnLang.pack
...
EnGB -> -- Add this line.
EnGBLang.pack -- Add this line.
This should result in a new language that works exactly as English does. You can now start changing the metadata.
In client/src/MassiveDecks/Languages/EnGB.elm
(replacing EnGB
with your language):
pack : Translation.Pack
pack =
{ code = "en-GB" -- Change this to the IETF language tag for the language.
, name = English
, translate = translate
}
You will notice that we also need a string describing the language.
In client/src/MassiveDecks/Strings.elm
:
-- Language Names
| English -- The name of the English language (no specific dialect).
...
| BritishEnglish -- Add this line.
Note that once you do this, you'll need to add a translation for this to every other language as well.
In client/src/MassiveDecks/Languages/EnGB.elm
(replacing EnGB
with your language):
pack : Translation.Pack
pack =
{ code = "en-GB"
, name = BritishEnglish -- Change this to your new string.
, translate = translate
}
You can now start changing the actual strings. These are created either from raw text or references to other strings:
MassiveDecks ->
[ Text "Massive Decks" ]
WhatIsThis ->
[ Text "What is ", Ref MassiveDecks, Text "?" ]
This will render was "What is Massive Decks?", but if you changed "MassiveDecks" to "Test", it would result in "What is Test?". This allows you to avoid translating the same thing many times and allows the text to be enhanced with things like links automatically.
In general, you should be able to just translate the raw text in quotes and shuffle things around. The more complex parts should pretty much remain as-is.
Note that some strings take arguments:
UserConnected { username } ->
[ Text username, Text " has reconnected to the game." ]
Note that some arguments are numbers, and these have to be converted to strings:
Score { total } ->
[ Text (String.fromInt total) ]
Note this is code, rather than configuration, so complex operations can be performed. Plural
is an example of this, as is asWord
. If you are not a programmer, these may be awkward - please feel free to explain the behaviour you need in a bug to get a developer to help out for awkward cases like different grammar rules for plurals, etc...