Skip to main content ↑ ↓
Topic: German in the code (Read 177444 times) previous topic - next topic

German in the code

Excuse my English

[EN]
It would be recommended that the comments, functions and variable names were in English. The German language keeps many people out of the code, I went mad because of dings, Ribi, etc.
A search and replace would help much, at least with the names of functions and variables.

[ES]
Sería recomendable que los comentarios, nombres de funciones y variables estuviesen en ingles. El alemán mantiene a muchos fuera del código, ya me tiene medio loco los dings, ribi, etc.
Una búsqueda y reemplazo ayudaría mucho, por lo menos en los nombres de funciones y variables.

Re: German in the code

Reply #2 –
ribi is not german either. It is just an artificial word form (Richtungs bits, aka english dibi from direction bits [so no improvement in english]). But you know, renaming everything would make nearly all patches useless ...

Whenever there is some renovation, we renamed some variables. But since the team size is that small, any additional work is not warmly embr****ed. Also many of the active developers were german, the only notable contributions from the non-german region were from kierongreen, Timothy, Knightly and z9999. It has also not stopped jamespett to branch into the experimental branch. Incidentally, this is not too different from TTDpatch, thus aparently german programmers have a liking to transportation games ...

You are welcome to do a patch to translate everything. Or add documentation. I do it, whenever we touch something old. But many parts are stable and thus I do not touch them.

Imho the biggest problem with a big projekt is, simply it is big. Even though simutrans is quite strongly modulized due to heavy OOP usage, most thing that can be achieved by a simple change have been already done. And for advanced stuff you need to dig into the code for a month or so to get an idea, imho. Perhaps ask Knightly or Dwachs about it, since those joined the team more recently.

Re: German in the code

Reply #3 –
I found Google Translator very helpful in deciphering German variable names. I understand the problems with translating the names, but perhaps there should be at least a concerted effort to put English translations into the code comments? That's what I do whenever I translate something for Experimental.
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Re: German in the code

Reply #4 –
amount of work required to translate code from German to English seem unimaginable. For instance, I attach patch that fixes "welt" and "Welt" to "world" and "World".

http://mallorn.ii.uj.edu.pl/~amelek/WeltToWorld.zip

877 kb unpacked patch file...

and obviously, some comments got messed up

Re: German in the code

Reply #5 –
Maybe a "Rosetta Stone" or "abbreviations/translation table" file, instead of trying to rewrite everything.

Re: German in the code

Reply #6 –
[EN]
It not seems so complex.
In the Visual Studio you can use the tool 'Replace in files', choose these options appropriate and replace all occurrences of a word in all files of the solution.

On the prevalence of German programmers think is partially due to this problem. Due to the size of the project is very difficult to understand the code and many give up.

Much of the time I lose in translating and find where things are, no doubt that ultimately succeeds in doing something but by that time I have learned a few words in German.

In addition there are almost no comments. If you could put a comment at the beginning of each file explaining that thing would help a lot.

[ES]
No me parece tan complejo.
En el Visual studio se puede usar la herramienta 'Replace in files', seleccionar las opciones adecuadas y reemplazar de un golpe todas las ocurrencias de una palabra en todos los ficheros de la solución.

Sobre la prevalencia de los programadores alemanes pienso se deba en parte a este problema. Por el tamaño del proyecto se hace muy difícil entender el código y muchos desisten.

Gran parte del tiempo lo pierdo en traducir y encontrar donde están las cosas, no hay dudas que al final se logra hacer algo pero para ese momento ya he aprendido unas cuantas palabras en alemán.

Además casi no existen los comentarios. Si se pudiera poner un comentario al principio de cada fichero explicando que cosa es, ayudaría mucho.

Re: German in the code

Reply #7 –
Simutrans is not that badly commented. Try out OpenTTD for a change ... (maybe the had improved meanwhile, but the last time I checked it was rather pages without comments at all.)

Commenting each file what it does would be nice, but I still have to see a real world project of similar size where this had been done and those header are still correct. Simutrans stems from a hobby project of Hajo (german) who tried himself to self study C++ by writing a program.

And you are right, there are tools that could do that. And all of them usually fail since simple searching and replacing does not always do the trick or a file is omitted. And it breaks all patches, which makes a lot of additional work.

Moreover, the function of an object is not dependent on the naming. If you have an idea, what dingliste_t does, I doubt you would have a different idea what thinglist_t or mononolisto_t would do. I had even a mathematic teacher who deliberately chose wierd names for variables to avoid to connect wrong ideas to the meanings for them.

If you consider to work on the code, just ask. This is usually 99% more helpful than searching through the code, because we can give answers like: "Drawing is done in simview.cc, which calls display_xxx from grund.cc and simplan.cc" Even with extremly well comments, figuring this out would have taken you longer than just asking.

Re: German in the code

Reply #8 –
[EN]
Well. I'll Ask.

About the patches, I don't know how they work.

[ES]
Bien. Preguntaré.

Sobre los parches, no se como funcionan.

Re: German in the code

Reply #9 –
I've certainly found language is a fairly minor obstacle when it comes to contributing to the code. For someone new to the code even knowing where abouts a particular change might have to be made could take several hours to work out due to the shear amount of code there, in comparison working out what a comment means (I only have rudimentary German, so might rely on google translate for some things) really doesn't take too long. The common variable and function names you pick up very, very quickly!

Re: German in the code

Reply #10 –
I had a slow migration to English names and comments in mind when the project started to be more than my personal toy. But as others pointed out, that was and still is quite difficult in some areas.

But I think we should still try to get there ... all new code should be English and all new comments, too. Samewise, changed code should be changed to English where possible, and changed comments, too. This way the code should become more international step by step.

I'm sorry for all the German in the code. It's been my only project where I used German for identifiers and comments, and just this one became popular enough that others wanted to participate ... bad luck :( In the beginning this was really just a personal toy project of mine.

Having said that, the one who wants to try a full translation of code and comments has my full support!

Re: German in the code

Reply #11 –
Quote from: Tubehead – on
I had a slow migration to English names and comments in mind when the project started to be more than my personal toy. But as others pointed out, that was and still is quite difficult in some areas.

But I think we should still try to get there ... all new code should be English and all new comments, too. Samewise, changed code should be changed to English where possible, and changed comments, too. This way the code should become more international step by step.

As a comment on priorities, I think full-length German words (Welt, Ding, Fabrik, Stahl, Weg, keine, etc.) aren't that much of a problem as they can be looked up in a dictionary or using Google Translate.

German *abbreviations* are confusing ("wkz", "ribi", "koord"); mixed language is confusing; ("has_diagonal_bild" -- should be has_diagonal_picture or hat_bild_diagonale, surely?) and in general abbreviations are very confusing ("get_wtyp")?  If anyone plans to do piecemeal change I suggest focusing on these.

Re: German in the code

Reply #12 –
Well get_ was gib_ before. Thus this is the result of automatic changing of the code as requested earlier.

Re: German in the code

Reply #13 –
Someone, I think Neroden, undertook a change to split gui_koord from koord. Maybe this new type can be named gui_coord, to be closer to English in the spelling?

Also, koord could be renamed to coord, (or point or point_t  maybe?) after the split.

Nothing serious, just suggestions to move to a more English codebase if things are in works anyways.

wkz_ could become tool_.

Re: German in the code

Reply #14 –
I guess it would be useful to share the current state of the little tool and the tables, no matter how messy and incomplete the whole thing still is (the translation table started as a quick setup to be able to evaluate the whole approach, therefore needs to be restructured). WARNING: RUN THIS ONLY ON A COPY OF THE FILES! They are expected in .\trunk-copy (I advise to use "clean"ed source code, the IDE, if any, must not keep the files open). The script needs Perl >=5.8, for Windows e.g. the free "Community Edition" from ActiveState: http://www.activestate.com/activeperl -

The file tr.cmd is a frontend to save typing on Windows, the actual file translate.pl should run on any platform (EDIT: but the file names will be shown with \'s). You might need to adapt the paths in it and then call:
tr phase1 check
tr phase1 sim
tr phase1 translate
tr phase2 check
tr phase2 sim
tr phase2 translate
The sim and check calls are optional and do not change the files. But if "check" shows warnings, sim/translate will fail. EDIT: A lot of output is printed on the screen - you better minimize the cmd.exe window or switch off debug output in order to achieve acceptable performance. If additional translations have been entered in the text tables, a delta update can be run with the same commands, but a check is not possible after translation, and phase 1 must not run after phase 2 changes have happened.

I do not have access to a (commercial) refactoring tool, which could do the whole job or at least help a lot. For parsing C++ (in Perl), I did not find much (as opposed to plain C), but if I use GCC's dump function, it would still be much easier (and probably faster at runtime) than writing a C++ p****r and dependency tracker on my own.
But this kind of understanding of the code would only save the unnecessary phase1 changes (due to false conflicts) and allow for better texts in some cases.

EDIT: the current version translates single words in comments, but not in strings of any kind.