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
[Discussion] Localization of an ink-based game #98
Comments
Hey! Yeah, there have actually been a few discussions on this topic, for example #89. The summary is: we don't currently have an "official" tried and tested solution since we've never attempted it ourselves. Our preferred approach would be to find a localisation team who would be willing to learn ink, and possibly encourage get their hands dirty with a little bit of logic tweaks, if they're necessary due to word order changing or even fixing word endings etc. On top of that, we've wondered about the possibility of creating verification tools to make sure that the translators don't accidentally break the high level structure of the ink, though it may be tricky to distinguish between breaking the high level flow, and tweaking the word by word language. |
Oh, thanks! Missed that post. As said there, anything that would make localization easier would be very helpful. In the meantime we'll work close to translators, trying to make sure they understand the basics. |
My experience with other scripts or languages for IF tell me that yes, extract strings of text and localise them with a external tool or database is not recommended because that is not as translating a normal game where you have a lot of code and then a little "It's dangerous to go alone! Take this". In IF games you have a lot of text and little code or logic, more true if it is a CYOA kind rather than a world model based game. I have remaked and localised to Spanish and English two games of 1986 Rod Pike's Dracula. The first I opted to have two different scripts, one for each language. This is obviously optimal because you can code in each localisation each idiosyncrasy of its language. However I just recommend this approach if you have a completely finished game, because, later, coming back and adding a feature, you must then cycle for each localisation adding that piece of code, and that is, a king of development hell. For the second part of the game I opted for including in each string of text every language (just two of them), and I used a python parser to filter through each language and compile in one language or another. That was better but because I was the sole dev. If I would pass the code to a translator, then they could mess with the code. In both cases I ended with two separate builds, one per language. With Ink, if you have a finished script, you can hand it to translators and later run the proper script for each language. but that do not prevent from creep through all scripts adding new features or bugfixes. So, I think the ideal approach would be an editor that allow to add strings of translations to each text bit, so you can easily track each language in context, and that it handles smoothly a database of localisation that is invisible to the script user. This is not going to help :) but, my two cents. |
More on the approach I think would be ideal for Ink. Here is some code from Dracula part 2, the remake I told you above: (Inform 6)
This is a first approach. Using compiler directives I duplicate objects, one per language. But this repeat whole blocks of code, and if you must fix or add a feature then you must make the change twice. Not much trouble, but sometimes in the log hours of fixing and updating, it is not rare to forget to change one of the languages in any object. If you want to go further and split at string level, this was not enough, because compiler directives must be used outside of objects. You can't split and fork inside an object in Inform 6, so I need to use a python parser to add tags that fork the code by language, let's cast an eye to this example from a game in German, with English, and a pending Italian localization:
So, I think this is the optimal way. If Ink would allow something like compiler directives or tags that allow to split the code arbitrary to insert strings of different languages, that would be a definitive solution for the problem at hand. Lets put an imaginary example, adapting an example of the Ink tutorial:
As you can see this is another kind of development hell. But I think that a proper IDE could do this internally and properly filter per language so a writer has not to make this to this level. And finally the message I want to transmit is that if Ink would have compiler directives, or the ability to fork the code previous to parsing it with Ink, then authors could try to handle the localisation problem in the way they considere better. |
Wow, that's very helpful, thanks! We're going to start with different .ink files for each language, we're only aiming for English and Spanish. Duplicating each line on the same line makes everything messier and harder to navigate, so we'll just duplicate every file and have the translators use the copy. We'll have to keep an organized database for changes, so we don't forget to make every change on both .ink files. On the other thread somebody sugested having an IDE which blocked ink syntaxis from being modified, while I get the point that it may be necessary for translators to change some of the syntaxis maybe it could be helpful. If it's something that happens every once in a while developers could take care of it manually. Everything depends on how much time devs need to spend fixing those lines and how many issues prevents for translators. |
When I had people localize story scripts for my previous game (not Ink scripts, but a very similar scripting language), what I did was to use a very simple convention for script constructs (e.g., writing all variables in ALL_CAPS or similar), and then I simply instructed the translators to avoid translating anything which was written using the chosen convention and created seperate files. This worked very well, with relatively few problems. |
I think you don't really need to teach of Ink to translator — most of .ink file is text anyway, and you can say, what things translators shouldn't change. And with help of Sublime you can make different color for all objects that are not text, this can be very helpful too. |
Idea: extend language with backticks (`) Backticks would mark a translatable line (would look like this: And add a translation mode to Inklecate, so that it gets two files - It's possible to build a gettext extractor/translator around Ink, as long as the language won't update and assign its own meaning to the operator. |
Hey there!
We're developing our main project using ink and we're loving it. Our studio is based in Madrid and, since most of the writers prefer working in Spanish, we're looking for somebody to do a proper English translation.
We could get every single piece of text, export it to excel and have them translate that, but we're aiming for quite a lengthy game, I guess it would take quite some time from development.
We could also try having them working with a copy of the .ink files, though we might need to check all the syntaxis later (would that be a huge pain in the ass? not sure).Translators would need to work a bit harder, since they would need to learn the basics of ink, but I guess it would also be easier for them to understand the meaning of each line of text.
We'll be working close to them to see what method is easier, but perhaps there's a better solution we haven't thought of. This topic might also be useful for more devs in the future so, what's your take on this? How would you do it?
The text was updated successfully, but these errors were encountered: