I18n support

[valerio-bozzolan]

Please start changing hard set private static final String values, to R.string costants :)

In order to allow users to submit custom value-*/strings.xml.

It will probably be a rather long operation.

(In a few weeks maybe I'll have time to help out!)

[00-Evan]

Adding in translation support is an oft-requested feature, and something I would like to do at some point.

Currently, it is not a priority though, especially as I am reworking large aspects of the current game, lots of translated text would need to be re-translated.

That being said, properly externalizing strings is something I could start doing immediately without issue, I will consider this in future releases.

leaving this open as a reminder.

[crafteverywhere]

If you have any plan about it, pls don't forget the messy problems about drawing CJK characters.
For now we have a repo of pixel dungeon for Chinese localization, you can use it as a reference as your will.

Our repo is here: https://github.com/WiseClock/localized-pixel-dungeon-gdx

[rakshazi]

Hello! Please, implement multilingual support ASAP, I want play Pixel Dungeon in russian language :)

pS: I can help with russian translation.

[sylvia43]

It's pretty easy to move String constants to R.string stuff. It'd just take a couple of hours. I might be able to get to it tonight. @00-Evan thoughts?

[00-Evan]

This is actually something I've been looking into recently, and was going to give an update regarding.

I don't think R.string is the right solution for this, as it is specific to android and therefore won't work with the libGDX port. My preference would be a solution that works on both versions. In addition, several strings may need to be tweaked in order to be more friendly to a separate strings file, and i18n in general.

Currently i'm in the middle of pushing to finish the next major update so I'm not looking into alternative right now, but I imagine whatever the traditional java way(resource bundles?) to handle i18n will be the most compatible between versions.

As far as doing it yourself, thanks for the offer but I don't accept pull requests, and any public translation efforts will probably be handled through a separate system that is more geared towards it.

[valerio-bozzolan]

If only there were a Free gettext<->R.string converter in the world. I always tried to start it...

[valerio-bozzolan]

Wow!
https://github.com/miracle2k/android2po

If it works you can start this i18n workflow:

• Someone release an initial .pot file with all the strings generated from the Android resources
• Users rename the .pot file in .po files and fill them with their localization using the Free/Libre software Poedit or using any online service like launchpad.net (that also is Free/Libre software)
• So sometime you convert your localized .po files into Android resources, or any other strange i18n format different from the wonderful GNU gettext.

[00-Evan]

I'm going to document work towards i18n here incase anyone is curious. This isn't a single-part job and I will be juggling it with other work, so don't expect this to be done right away. Feel free to keep discussing.

Indev i've changed how bitmap text works within the game. Rather than having 5 font sets the game now works with only 2, the 1x and 3x fonts(now named pixelfont and font). pixelfont is used in places where it is specified for stylistic reasons and on extremely small displays. regular font is used in all other cases and openGL scaling is used to make it look at least reasonable on all display sizes and scalings.

This makes font more consistent over different devices, but more importantly it means new characters for i18n need to be added to only two bitmaps instead of 5. Furthermore at all but the smallest of displays and resolutions (I'm talking 2.7" phones from 2010 here) will now have proper bitmap space to add accent characters.

Will edit this comment to reference the commit when the source for 0.3.1 is released.

[00-Evan]

I've done some investigation on current users from non-english languages.

Initial release of i18n is going to focus on French, German, Polish, Russian, and Spanish, which collectively account for ~19.5% of shattered's total userbase, which is ~63% of shattered's non-english speaking userbase. This will expand official language support from ~69% of all current users to ~88.5% of all current users, according to google play statistics.

I'm well aware that languages like Korean, Chinese, and Japanese make up a large number of players of RPG games on google play, but I want to enhance the game for the largest portion of existing users first before fishing for new ones. In addition I have received the most translation interest from the community for the currently focused languages, meaning it will be most likely that those will receive adequate crowdsourced translation support.

This will mean implementing characters from west-latin, central-latin, and cryllic character sets. Rather than fully implementing those sets I'm going to implement specific characters as they are needed, with common ones for each language done pre-emptively. It makes more sense to do characters this way as their use is controlled, no sense in designing characters that the game is probably not going to use.

Obviously the major barrier here is still string externalization (adding characters for phonetic languages will also be a nightmare but we're not addressing any of those yet). That will probably be the next major issue I look into, no ETA on that yet.

[00-Evan]

Currently planning to do string externalization either in 0.3.3 or in one of 0.3.3's patches.

I'm investigating solutions and wondering if anyone has suggestions. android's R.string does not work as it's incompatible with the GDX build. There are just plan Java .properties files and resource bundles, but i'm not sure if that's the best solution.

[bobdos]

Hi, Evan. For the language, such as Korean, Chinese, and Japanese, I suggest that we could use system font or TTF font is enough, instead of bitmap. Because those characters in bitmap format would cause the bitmap pictures too big.

[bobdos]

Evan, I agree with you to use the solution by using .properties files and resource bundles, especially for the gdx build.

[00-Evan]

Using a system or TTF font is certainly possible, but I want to do everything I can to retain the pixel graphics style of the game. The biggest problem I've seen with other translated versions of the game is that the text looks awful next to the pixel art graphics.

[00-Evan]

I've been busy over the holiday externalizing almost every string in shattered pixel dungeon. Expect to hear news on a crowdsource translation site very, very soon. I'm going to be playing this by ear a bit so while (I hope) all the string externalizing is a one-time job, there may well be issues that crop up which will require new i18n logic or other such corrections.

The translation platform I'm using will have a small forum for discussing with translators. For that reason, once that site is up i'm going to lock conversation on this ticket in the interest of moving all i18n-related discussion, (technical or not) to that platform. Given that that site is where all the actual translation will happen it doesn't really make sense to keep talking about it here where it won't be as visible to translators.

Don't worry, you will be able to sign in with your github account.

[00-Evan]

The transifex site can be found here:
https://www.transifex.com/shattered-pixel/shattered-pixel-dungeon/

There are a LOT of code changes being made to support this, so ticket will be closed once the source is released, but the relevant commits will be something like 90% of 0.3.4

[brunal]

Having Pixel Dungeon in my mother tongue is very nice, but

• given that French is quite verbose, some strings will wrap/be cut when displayed.
• the font has changed, and I find the new one to be less in accordance with the general PD theme. It does not look half as nice; it'd be nice if I could choose to keep using pixelfont for everything.

[00-Evan]

@brunal

Several languages have had some text length issues, we currently dealing with them on a case-by-case basis but usually some mixture of translation compromise and UI tweaking has gotten everything working so far. French is currently about 50% translated so the priority is getting all the translation done first before checks are done to make sure it all fits.

As for the text style, I agree that the new font is less pixely, but it is much cleaner and easier to read, I feel like it's superior to the previous font even if it doesn't fit the art style quite as well. Putting the old pixel text back in just isn't really feasible as it's extremely limited and I want to move forward from it.

The new system does however have the ability to use different vector-based fonts, so it is entirely possible to use a different font which both improves text fidelity and fits the art style a bit better. The major issue is that said font needs to support a LOT of characters to be feasible, I don't want to have to use different fonts for different character sets, and most fonts do not support Chinese characters.

[00-Evan]

source has now been released.

Adding i18n involved, among other things, building a messages class to handle string externalization, and a rendered text system to replace the old bitmap text. Relevant commits are most of 0.3.4's ~200 commits.