Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request]: allow for easier language preview from Translator to in-game #9590

Open
kneekoo opened this issue Oct 2, 2021 · 7 comments
Open

Comments

@kneekoo
Copy link
Contributor

@kneekoo kneekoo commented Oct 2, 2021

Version of OpenTTD

12.0-rc1, Linux Mint 20.2 Cinnamon (based on Ubuntu 20.04), using openttd-12.0-RC1-linux-ubuntu-focal-amd64.deb

Expected result

Translators should be able to download the compiled translations directly from Web Translator, instead of having to compile anything. It's not just me, as a translator, who doesn't want to waste time compiling strgen, but I'd also like to easily share the file with a friend, so he can help me check the quality of the translation.

Please never expect translators to have any OS/sysadmin/programming skills. Even when they do have all of that experience, it's counter productive wasting their time going through outdated guides onyl to find out that strgen is unavailable and then search for other ways to get it. That time should be spent on translating and checking.

Actual result

The compiled version is missing.

Steps to reproduce

Open this page and you will only find Download Lang File, which is the text version of the translation.

@nielsmh
Copy link
Contributor

@nielsmh nielsmh commented Oct 2, 2021

I wonder if there's any good reason the main OpenTTD binary can't simply load translations in text format itself. The compiled format has some advantages in loading time, but all the code to load a language file is basically already compiled in, since the language files for AI/GS are loaded from text format at runtime.

Loading

@glx22
Copy link
Contributor

@glx22 glx22 commented Oct 2, 2021

WT only knows master branch (used for nightly builds), so it may be very hard to get compiled lang file for other versions from it.
Also the lang file you can download is only valid for master branch (most of the time it should work in other versions too unless some strings format differ in english.txt between master and other version).

Loading

@kneekoo
Copy link
Contributor Author

@kneekoo kneekoo commented Oct 2, 2021

I wonder if there's any good reason the main OpenTTD binary can't simply load translations in text format itself.

Yeah, that would be helpful. The game could even auto-detect the format if provided manually or as .txt/.lng and load .lng as default if both are present.

WT only knows master branch (used for nightly builds), so it may be very hard to get compiled lang file for other versions from it.

While that's perfectly understandable, generally speaking translators only need two versions of the language file: one for the stable version and one for the latest development release. If WT could provide both, great. If not, the compiled version would still be useful for the latest beta/rc testing, especially as changes in locale support are uncommon.

Loading

@TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented Oct 3, 2021

This is basically a feature-request hiding as a bug :D

We have learnt over the years that making strgen available isn't any solution, and allowing .lng files to be downloaded via the translator tool is neither. It is very confusing to most users that they are tightly coupled to a version of OpenTTD; and the errors shown when you make a mistake are not really helping either.

A solution like @nielsmh is much more robust in that sense. I once also made a coupling between OpenTTD and the (now offline) WT3, where changes in WT3 would show up live in the game. It was a fun gimmick, but a lot of problems came from it (windows don't resize etc etc). In the end, it was not all that useful.

By classifying this as feature-request, and changing the title a bit, it allows for a broader scope of solutions. Hope you don't mind :)

Loading

@TrueBrain TrueBrain changed the title [Bug]: strgen should be integrated with the translation system [Feature Request]: allow for easier language preview from Translator to in-game Oct 3, 2021
@TrueBrain
Copy link
Member

@TrueBrain TrueBrain commented Oct 3, 2021

PS: the flow I found easiest, to help in your workflow: changes you make are committed daily, and show up in the next nightly. So showing a friend to see if the translation is an improvement often means waiting for the nightly and ask them to validate that. It makes iterations a bit slow, but resolves all of these problems.
And as we publish nightlies to Steam, those using Steam can get the latest and greatest without any fuzz.

Not disagreeing that this can use some improvement btw, but just making sure you are aware of this process :)

Loading

@nielsmh
Copy link
Contributor

@nielsmh nielsmh commented Oct 3, 2021

If the game can load translations from the text format, then it won't be a (big) problem if the language file doesn't match the game version exactly, because there no longer needs to be a direct correspondence between the string ordering and such from the english.txt strings to the translated strings. Any mismatches are already detected by strgen and so it would be possible for text string loading in the game itself to detect those too, and ignore the problematic strings. (For example, wrong number/ordering of inserts.)

Another idea could be to include a tool in-game to help you find a problematic string in the translation data. Dream scenario would be, you see some poorly formed text in the game, point at it, and get the StringID(s) involved.

Loading

@michicc
Copy link
Member

@michicc michicc commented Oct 3, 2021

I guess the super-fancy solution would be to have a "run now" link on WT which launches an emscripten version with the current language (maybe as txt) injected into.

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants