Translations

[galehar]

Work has begun on the code infrastructure to support translations. We now support translations of descriptions. Big thanks to kilobyte!
There is still a lot of coding to be done, but in the meantime translations of descriptions can begin. So volunteers, please step forward and announce your native language! We also need one "leader" per language to dispatch work, set up big online spreadsheet like grimm did for the DTIT and submit patches.

Also see this post for further guidelines on text work.

[CommanderC]

I think I can help with the spanish translation.

[mageykun]

I can do the American translation! I'll begin pruning all those extra u's immediately.

Seriously, good luck with the translation projects. I've had the pleasure of enjoying some great games that migrated to English, kinda cool to see something as great as crawl getting exported. Us monolingual-ed folks depend on you to spread awesomeness around!

[CommanderC]

galehar, the files to be translated are source/dat/database/*.txt and source/dat/descript/*.txt. Am I missing other files?

[galehar]

only dat/descript for now

[Grimm]

I don't recommend Google Docs for any spreadsheet work. It doesn't have a good way to keep track of changes.

[dk]

Ich spreche Deutsch und würde mich freuen, ein paar Texte zu übersetzen.

I'm speaking german, so I would like to help

[Pereza0]

Native spanish here, will probably do some work

[TehDruid]

Native Greek here. Don't speak ancient greek though, sorry. I'd be willing to set some of my free time apart to do this and work on my translation skills. I'm a pretty good user of the English language I believe.

The thing is, for a person to dabble into roguelikes, it's most probably a sure thing that they know how to speak English well so I don't know how important translation is, seeing how obscure the game is anyway... But don't mind me. I still want to help. Just show me the way.

Translation of the above;

Γηγενής Έλληνας εδώ. Δεν μιλώ αρχαία ελληνικά όμως, συγγνώμη. Προτίθεμαι να διαθέσω κάποιον από τον ελεύθερο μου χρόνο για αυτό, πράγμα που θα βελτιώσει και την ικανότητα μου να μεταφράζω. Είμαι αρκετά καλός χρήστης της αγγλικής γλώσσας, πιστεύω.

Βέβαια, για να ανακατευτεί κάποιος με τα roguelike, το πιθανότερο είναι πως γνωρίζουν να μιλούν Αγγλικά καλά, οπότε και δεν ξέρω πόσο σημαντική είναι η μετάφραση, όταν μάλιστα το παιχνίδι είναι τόσο "αφανές". Αλλά μη σας απασχολεί αυτό. Eπιθυμώ να βοηθήσω όπως και να 'χει. Απλά δείξτε μου τον τρόπο.

By the way, there's no Greek section in "The Annex". Perhaps some people want to work on their use of the language (although I'm probably the only one that can use it, not sure though)? I can always try and help if someone is studying something in Greek and having trouble. I'm no philologist though. I guess a barkeep can make a topic for this?

[varsovie]

I could help translate some stuff in french, but I don' want to be the leader since I do suck in French ( F*ing grammar!).

[banei]

[french]
Je peux vérifier la traduction française, mais je n'ai pas le temps pour faire la traduction comme telle. Ma blonde est traductrice, mais elle déteste Crawl

[MyOtheHedgeFox]

I'd be glad to say "I'll step in for Russian translation!", but -- I really have too much to do, and, sadly, I am pretty unreliable in that sort of thing.

К сожалению, принять участие в переводе сейчас не могу, но если нужно проверить тексты на орфографические/грамматические/пунктуационные/речевые ошибки, зовите. =)
And if nobody steps in until May, for example, so be it -- I'll start working on it!

But, just in case I am going to change my mind about it in the next days -- where should I upload the translation results? Anywhere I see fit?

[galehar]

I don't recommend Google Docs for any spreadsheet work. It doesn't have a good way to keep track of changes.

But, just in case I am going to change my mind about it in the next days -- where should I upload the translation results? Anywhere I see fit?

I think using the dev wiki should be a good way to organize team work on translations (this is also true for the next iteration of DTIT if there is one).
For the ones working on their own, putting their work on the wiki is still a way to make it available. Or just upload it on mantis. Making a gitorious clone and requesting a pull is also possible, but it's mostly handy for merging code with lots of commits.

[MyOtheHedgeFox]

And, I second Grimm:

I do not recommend Google Docs.

My interest towards a certain translation project (abandoned, sadly...) decreased rapidly because all the documents we had to translate were uploaded to Google Docs, and download-uploading them for off-line translation was a pain.
But that was not the worst. Google Docs might hang, and if it hangs (because of a slow connection or because you use NoScript to block some of the Google's spy-domains, for example), your changes are as gone as that level four Spriggan Wanderer ghost blasted with a Fire Storm. And that is ve-e-ery painful, especially if you type fast and rely on auto-save feature too much. Remember: in on-line, autosaves can and will fail you, just like that Maxwell's Patent Armour.

It was not the only reason, and yet...

[Grimm]

I think using the dev wiki should be a good way to organize team work on translations (this is also true for the next iteration of DTIT if there is one).

I'm willing to move the current iteration of DTIT to the wiki now, if someone is willing to give me some pointers. XuaXua?

[jpeg]

I agree that the (or a) wiki sounds like a good place to collect translations-in-progress. If the development wiki is used for this (which makes sense), it might help if someone defined a template translators could use. Ideally, this template already takes into account stuff needed for later, such as a separate mention of an entry's gender or plural form.

Organization-wise, the first step is probably to translate item/feature/monster names. Also, to avoid wasting time on throw-away translations, only descriptions already approved by Grimm's task force should be up for grabs. Posting separate lists of items/monsters/etc. whose descriptions are considered finished would provide a good starting point for would-be-translators of all languages.

Once this has been set up, I think this project should be announced in the dev blog.

Oh, and I'd be happy to help out with some German.

[MyOtheHedgeFox]

And, just in case, let's borrow some translation guidelines from big OSS.

Wesnoth translation guidelines for Russian language seem to be more than suitable, for example.
http://wiki.wesnoth.org/RussianTranslation (scroll below the large table)

The page has a lot of links to nice sites with required special symbols, e-books and materials written by excellent translators, editors and linguistics professors of Soviet times...
Well, at least there is one really good e-book.

I believe there should be something else for all the other languages available in Wesnoth. Look for them. =)


К слову, товарищи любители русского языка: если нужны книги по переводу, могу скомпоновать для вас большу-у-ую коллекцию. Профессия будущая как-никак.

[galehar]

I've made a script which creates a doku wiki table from the existing descriptions and quotes. Here is a preliminary result. Obviously, we're going to need to the tablewidth plugin. I'll try to set it up or ask Napkin to do it.
edit: I've installed it, but it doesn't seem to work
I've used a single column for review. We can use some code like D+Q- to mean descriptions have been reviewed and is good, quotes have been reviewed and isn't good.
I'm taking any suggestions regarding the workflow or the table.
The good thing is that dokuwiki tables are easy to parse. Maybe I can write another script which download all the descriptions and quotes which have been reviewed and update the local copy of the source. Then it's just a matter of final review, git commit -a, git push.

[jpeg]

I've made a script which creates a doku wiki table from the existing descriptions and quotes. Here is a preliminary result.
I've used a single column for review. We can use some code like D+Q- to mean descriptions have been reviewed and is good, quotes have been reviewed and isn't good.
I'm taking any suggestions regarding the workflow or the table.

I'd put the quotes onto a separate page, for three reasons:
1) Quote translations have a much lower priority.
2) Now that the fixed width plugin works, the columns will get really cramped once they actually get filled out.
3) Ideally, quotes shouldn't have to be translated. Rather, someone needs to hunt down a professional translation of the source that is being quoted and use that one.

Handling names on a separate page would also work, but might be overkill, not sure about that.

The translation wiki probably will need some guidelines to help translators along. The first common problem that springs to mind is how to deal with the gods' genders. (In German, generally the male form is used for unknown gender, but that feels somewhat wrong in this context as it defies Crawl's tradition of genderless gods.)

Also, what about stuff like species descriptions? Are these also included in the description overhaul, or are they good to use?

[MyOtheHedgeFox]

We can use neutral gender in Russian (Божество [deity], neu. instead of бог [god], mascul.). Are there any equivalents of this in other languages, friends?

I myself would actually put up the question of deity gender and state it outright. Perhaps we should ask Linley himself.

And again, speaking of guidelines: I would suggest those who want to translate the game find a good book on translation (or even a few) from the "golden times" of No Automatic Translation Systems Age and follow the advice from this source.

[nicolae]

I myself would actually put up the question of deity gender and state it outright. Perhaps we should ask Linley himself.

It has already been stated outright by the devs: the gods don't have explicit genders.

[galehar]

I'd put the quotes onto a separate page, for three reasons:

Good point. I'll do that.

[MyOtheHedgeFox]

I myself would actually put up the question of deity gender and state it outright. Perhaps we should ask Linley himself.

It has already been stated outright by the devs: the gods don't have explicit genders.

In traditional mythology, gods have them -- or at least have them stated outrightly.

But -- oh well. What should the translators do with them? Use neutral gender if possible or imagine something on their own? And finally state that Vehumet is of female gender? >.<

[jpeg]

It has already been stated outright by the devs: the gods don't have explicit genders.

In traditional mythology, gods have them -- or at least have them stated outrightly.

Crawl does use a mythology of its own, in which gods just happen to be genderless beings.

But -- oh well. What should the translators do with them? Use neutral gender if possible or imagine something on their own?

Several routes are possible:

a) try to enforce genderless translation

This won't work in all languages, and may sound wooden and artificial in others. For example, in German you could say "this god or goddess" but German already tends to use long words and will have enough trouble to stay within the length restrictions without adding artificial means to make texts even longer. I've finally remembered the term "Gottheit", which is sort of gender-neutral (closer than "Gott" in any case), even if it uses the female grammatic gender. That one might actually work.

b) ignore the issue and just use whatever is normally used for unknown gender in the given language

In effect, this is likely to have all gods appear as male in the greater part of languages. I really don't care much for this solution as it would cheapen a part of Crawl's mythology.

c) assign the gods genders as translators see fit

This is likely to result in the gods having different genders in different languages, which might be an indirect way to say "we don't know". This one might very well be the most practical solution.

d) randomize god gender per game

This would complicate the descriptions a bit as they would have to contain placeholders to be replaced with "this god" or "this goddess" as appropriate. Also requires coding to handle gender for all the gods, though that will have to be done for items and monsters anyway. Still, extra work for flavour that might end up confusing people.

[TehDruid]

This thing with gods and gender is quite an issue... See, in Greek I believe the use of articles is much more extensive than in English.

Example:

In English you say;

All work and no play makes Jack a dull boy.

A word-to-word translation would be;

Όλο δουλειά και καθόλου παιχνίδι κάνει Jack ένα βαρετό αγόρι.

Notice that no person in Greece would say this phrase in this manner. Ιt would sound retarded here. Instead you'd say something like;

Ο Jack είναι βαρετός επειδή το μόνο που κάνει είναι να δουλεύει συνέχεια και δεν ξέρει να διασκεδάζει.

Which in English again would translate, roughly;

Jack is boring because all he does is work and doesn't know how to enjoy himself.

Anyway, notice the 'Ο' before the name Jack in the second sentence in Greek? That's a singular masculine article. If you don't put it there, you're going to sound stupid. And you're going to sound even more stupid if you use the singular neutral article, 'Το'. There's also others, depending on conjugation (if this is the right word).

So, to be honest I don't have a clue how I could translate the god lines.

By the way, I'm not really good with grammar and all things philological. I'm more of a Chemistry/Biology fan.

[mumra]

I'm taking any suggestions regarding the workflow or the table.

When all is in order, the process will be: type your description/quote in a text editor. Replace all new lines by \\ followed by at least one space. Copy/paste it in the right cell.
I don't think we can make it better, but if anyone has some dokuwiki skills and/or know some editing plugin, please yell.

A straightforward desktop tool could at least be written to automatically convert a csv spreadsheet to/from the docuwiki syntax. Then people can use the spreadsheet editor of their choice. That alone would make the process drastically smoother, especially when a translator might be updating multiple entries in one go. Doing that conversion by hand for each one of 1,000 language entries will be far from fun (and as a completely wild estimate, Crawl probably has many 1,000s of individual items of language).

Whilst I can see that using the wiki has some advantages in this application, I would argue that it's basically not designed as a workflow tool. Is writing all these import/export/filter scripts going to save that much time vs. building a proper tool (desktop or web) for easily updating the language DB, which could save countless man hours for both translators and reviewers by being a bespoke and integrated workflow instead of combining all these different tools and manual processes? Also remembering that any human process is prone to error, which is of course why you want as much automated as possible

There also seems to be some reliance on using the wiki history to see changes, but it's not always super easy to read and understand, and it isn't perfect - for instance it shows the differences between a given revision and the current one, but it doesn't have an obvious way to compare two specific revisions unless they're the two most recent.

[galehar]

A straightforward desktop tool could at least be written to automatically convert a csv spreadsheet to/from the docuwiki syntax.

Converting a dokuwiki table in csv is indeed trivial. Anybody can copy/paste the dokuwiki table in a local file, import in a spreadsheet editor, edit the entries, export it back to dokuwiki and paste it into the wiki editor. I don't think it's easier though, unless your editing dozens of entries at once, which seems unlikely.

Whilst I can see that using the wiki has some advantages in this application, I would argue that it's basically not designed as a workflow tool. Is writing all these import/export/filter scripts going to save that much time vs. building a proper tool (desktop or web) for easily updating the language DB, which could save countless man hours for both translators and reviewers by being a bespoke and integrated workflow instead of combining all these different tools and manual processes? Also remembering that any human process is prone to error, which is of course why you want as much automated as possible

The script/wiki solution I'm setting up is an alternative to using google docs, which has been tested and considered inappropriate by the DTIT. A more advanced tool would obviously be better, but we don't have one. Are you volunteering for writing us a tool with a web form or something? If anybody is, that would nice, sure.
The wiki may not be designed as a workflow tool, but it is designed to ease collaborative work. And our workflow is really simple.

There also seems to be some reliance on using the wiki history to see changes, but it's not always super easy to read and understand, and it isn't perfect - for instance it shows the differences between a given revision and the current one, but it doesn't have an obvious way to compare two specific revisions unless they're the two most recent.

That's true, and it's annoying. A way to view the diff between any 2 versions would be great, and I'm pretty sure there's a trick or a plugin to do it.

[Kate]

Huh? You just check the boxes for the two revisions you want to compare and click "Show differences between selected revisions".

[mumra]

A straightforward desktop tool could at least be written to automatically convert a csv spreadsheet to/from the docuwiki syntax.

Converting a dokuwiki table in csv is indeed trivial. Anybody can copy/paste the dokuwiki table in a local file, import in a spreadsheet editor, edit the entries, export it back to dokuwiki and paste it into the wiki editor. I don't think it's easier though, unless your editing dozens of entries at once, which seems unlikely.

I'd disagree. When a new language is added, the translator will be creating 100s or 1000s of entries at once. Not to mention something like a new god or other biggish feature being added/modifed and every single translation needing dozens of new bits. Spreadsheet editors also have good sorting and filter tools.

Whilst I can see that using the wiki has some advantages in this application, I would argue that it's basically not designed as a workflow tool. Is writing all these import/export/filter scripts going to save that much time vs. building a proper tool (desktop or web) for easily updating the language DB, which could save countless man hours for both translators and reviewers by being a bespoke and integrated workflow instead of combining all these different tools and manual processes? Also remembering that any human process is prone to error, which is of course why you want as much automated as possible

The script/wiki solution I'm setting up is an alternative to using google docs, which has been tested and considered inappropriate by the DTIT. A more advanced tool would obviously be better, but we don't have one. Are you volunteering for writing us a tool with a web form or something? If anybody is, that would nice, sure.
The wiki may not be designed as a workflow tool, but it is designed to ease collaborative work. And our workflow is really simple.

Yes, I saw some comments about Google Docs not being appropriate ... really it's for the same overall reason, that it's just not a tool geared to the task. The wiki solves some problems but I'm sure it'll introduce others - of course these might not become apparent until theory turns into practice! Having spent some time using the wiki for a non-trivial task (specifically the vault design reference) I guess my biggest worry would be that it's not a very convenient tool for working with large amounts of data.

It doesn't look like an insurmountably huge task to build a simple web interface to make things easier; I'd like to help but I can't make any promises in the immediate future

[mumra]

Huh? You just check the boxes for the two revisions you want to compare and click "Show differences between selected revisions".

Huh. You're right, that was pretty obvious ;P I don't know why my brain never registered that, those tick boxes have clearly always been there.

[mumra]

My next thought was - there are probably tools already geared much more specifically towards this scenario.

The first one I found was Transifex - http://www.transifex.net

It supports a variety of formats including MediaWiki and is a dedicated collaborative localization tool. It has a free unrestricted plan for open source projects.

[galehar]

It doesn't look like an insurmountably huge task to build a simple web interface to make things easier; I'd like to help but I can't make any promises in the immediate future

I agree, a simple web interface should be pretty easy to code. Using Transifex or a similar tool can be an interesting solution too. But I don't have the time for either of this. I'd rather code on crawl. You know, I do have permabuffs on my todo
I just tried to set things in motion with the wiki script. I'll stop for now and hope somebody volunteers for setting up tools for translations and text improvement. If nobody does, I'll finish it.

[Grimm]

Just had a quick look at Transifex - it could be exactly what we need. If there is no opposition I will start getting us set up on it.

[MyOtheHedgeFox]

I am for Transifex, too! It already has some basic grammar support, it can be locked for special translation groups (and it can lock a file if a certain group member is working with it). I used it for FocusWriter, and it looked like a very nice Launchpad Translations version, much faster and more convenient!

If it requires any fee to be used for a large project like Crawl, please send me a private message to me, Grimm -- I'll chip in.


Another thing about translation bug reports... I think very few people would like to register on a Fairly Strange Site, find That Required Button and fill a Very Large Form.
What if we include an e-mail and some other contact data (ICQ/AIM, Facebook/VK.COM links...) of (the leaders of) translation groups in the main page (somewhere around "Take part in the Stone Soup Survey", but written in rainbow letters of immediate attraction)? If there is anything we must be social for, that's that.
Russian translators: we WILL have to include a VK.COM group, whether we want it or not. Happily, all those social networks have e-mail notifications...

[dk]

I think transifex is free for open source projects, IIRC (the hosting service they offer).
But maybe someone could setup a transifex-server just for crawl? It's open source by itself (it's a djange website).

[mumra]

I think transifex is free for open source projects, IIRC (the hosting service they offer).
But maybe someone could setup a transifex-server just for crawl? It's open source by itself (it's a djange website).

Yes - I said so when I gave the link

A custom server could be useful tho for setting up automated pushes and pulls to the Crawl repo.

[galehar]

I think transifex is free for open source projects, IIRC (the hosting service they offer).
But maybe someone could setup a transifex-server just for crawl? It's open source by itself (it's a djange website).

Yes - I said so when I gave the link

A custom server could be useful tho for setting up automated pushes and pulls to the Crawl repo.

I don't think we want to go that far with automation. Don't want a contributor to break the build process with a typo for example. There still need to be a dev at the end of the process, doing a final review, committing and pushing the changes. Therefore, I don't think we would have any use for a custom server. If the free hosted server meet the needs, I don't think we should waste time setting up and administering our own server.
Anyway, what's the input/output format? Don't we need to format our strings in a csv or something?

[dk]

I think transifex is free for open source projects, IIRC (the hosting service they offer)....

Yes - I said so when I gave the link

....

Sorry, I was still tired while reading your post

[dk]

...

Anyway, what's the input/output format? Don't we need to format our strings in a csv or something?

Have a look here here.

Btw, how is the text going to be translated? Do you plan to use something like gettext?

[mumra]

I think transifex is free for open source projects, IIRC (the hosting service they offer).
But maybe someone could setup a transifex-server just for crawl? It's open source by itself (it's a djange website).

Yes - I said so when I gave the link

A custom server could be useful tho for setting up automated pushes and pulls to the Crawl repo.

I don't think we want to go that far with automation. Don't want a contributor to break the build process with a typo for example. There still need to be a dev at the end of the process, doing a final review, committing and pushing the changes. Therefore, I don't think we would have any use for a custom server. If the free hosted server meet the needs, I don't think we should waste time setting up and administering our own server.
Anyway, what's the input/output format? Don't we need to format our strings in a csv or something?

My theory was that an entry is marked for "review" after a contributor has updated it. It only gets pushed automatically once an actual dev sets the status to "accepted". Anyway yeah, it's not necessary.

They have a variety of input/output formats. I mentioned in my previous post - they even support wiki. http://help.transifex.net/features/formats.html#user-formats

[MyOtheHedgeFox]

If we are going to use Gettext format, we must find a nice editor for it (apart from a Notepad) or else it'll turn into a GoogleDocs-horror.
Poedit won't help: this bugger has no undo-redo feature!

[varsovie]

Kbabel now Lokalize, Emacs, Vim or anything you like (I use Kate).

Spellutils and Gettex too may be needed.

[mumra]

Since it seems Transifex is being looked at, perhaps none of that will be needed. Transifex provides a web interface: https://www.transifex.net/tour/fortranslators/

[XuaXua]

What are the mechanisms being used for text encoding?

[MyOtheHedgeFox]

As I mentioned in my message on Google Docs, having only an on-line interface is not enough sometimes. Offline text editors are still a tad more reliable. =)

Thanks, Varsovie!

[mumra]

As I mentioned in my message on Google Docs, having only an on-line interface is not enough sometimes. Offline text editors are still a tad more reliable. =)

Thanks, Varsovie!

You have options:

a) Edit in your favourite editor and copy/paste (this is how I tend to do work on large wiki pages anyway)
b) Edit the language files directly in the Crawl source using any text editor, since the workflow should support both push and pull from git
c) Export from Transifex into one of the many formats it supports, edit that, reimport (Transifex supports merge operations)

[galehar]

What are the mechanisms being used for text encoding?

UTF-8 Unicode text

b) Edit the language files directly in the Crawl source using any text editor, since the workflow should support both push and pull from git

But we aren't gonna give commit rights to all translators.

OK, on the dev side, the implementation of translations is "on hold". I asked kilobyte to focus his effort on the portal_branches (a git branch to fix a bunch of stuff related to portal vaults and branches). In the meantime, you guys can figure out how to organize yourselves, what tools to use and start translating descriptions. If you don't, I'll finish my script/wiki set up, since it's better than nothing.

[XuaXua]

As I mentioned in my message on Google Docs, having only an on-line interface is not enough sometimes. Offline text editors are still a tad more reliable. =)

Thanks, Varsovie!

You have options:

a) Edit in your favourite editor and copy/paste (this is how I tend to do work on large wiki pages anyway)
b) Edit the language files directly in the Crawl source using any text editor, since the workflow should support both push and pull from git
c) Export from Transifex into one of the many formats it supports, edit that, reimport (Transifex supports merge operations)

This doesn't always work when you are playing with text that must be encoding-specific. Depending on your platform and editor and choice of where you are cutting and pasting, you can lose encoding and the end result is corrupted text. Even when it appears correct to you when you save it.

Meticulous standardization and governance rules are key.

[MyOtheHedgeFox]

If you export something via Transifex/Launchpad/etc, it almost always gives you a Unicode tex... hm, yes, Xua, you are right!

Windows users, install Notepad++ and make sure that the encoding is always UTF-8 (preferrably UTF-8 without BOM).
Linux users, you can use your beloved text editor (just make sure to save the file in UTF-8; that should be the default setting for almost all of them!). If you want something resembling Notepad++, try Geany. Ubuntu users can stay with Gedit, too.


By the way! What should we do with "hungry kobolds", "deformed mermaids", "spectral dragons" and other vault-specific monsters?
Can they be "out-defined" into a single file, so to say?

[mumra]

If you export something via Transifex/Launchpad/etc, it almost always gives you a Unicode tex... hm, yes, Xua, you are right!

Windows users, install Notepad++ and make sure that the encoding is always UTF-8 (preferrably UTF-8 without BOM).
Linux users, you can use your beloved text editor (just make sure to save the file in UTF-8; that should be the default setting for almost all of them!). If you want something resembling Notepad++, try Geany. Ubuntu users can stay with Gedit, too.

I suggested creating a "Translators' Guide" wiki page for any information like this, and of course a walkthrough of the whole process once it's all in place.

By the way! What should we do with "hungry kobolds", "deformed mermaids", "spectral dragons" and other vault-specific monsters?
Can they be "out-defined" into a single file, so to say?

This is something people are aware of. There's a lot of other language that comes from vault files; e.g. portal timer messages and other miscellaneous prompts, all generated in LUA code. I think right now just getting items working is a big enough challenge