News:

Simutrans.com Portal
Our Simutrans site. You can find everything about Simutrans from here.

German in the code

Started by felo, March 10, 2010, 05:48:22 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

Markohs

 Not being a german speaker myself, and finding german in code something that makes the development harder, I think the translation it's not really possible or worth, because of the reasons prissi already mencioned, mainly:

- It whould make experimental and branch simutrans ever harder to keep in sync (well in fact it whould break all chances to keep it in sync)
- I think it whould add lots of bugs and whould take lots of work.
- Whould make all patches useless.
- There is some documentation isidoro is working in that documents the code in depth, that's a great point to start reading and learning the code.

I'd personally just:

- Write in english NEW parts of the code, but variables and classes that already exist should remain as they are.
- Keep isidoro's and rest of documentation up to date.
- Translate all the code comments, there are a few still in german.

VS

But... this isn't about changing the system, just names. How hard is it to do search & replace? After all, both of prissi's warning examples involved different code, not names.

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Ters

How can you search and replace in files on someone else's computer, that might be on the other side of the world and turned off at the moment? I have been a professional software developer for only a couple of years, but have seen many obviously harmless operations go very wrong.

Spike

I guess it's the time to respect Prissi's voice as the current head developer. He says 'no' to the idea, and so we should spend our time on more worthy targets.

jamespetts

Quote
- It whould make experimental and branch simutrans ever harder to keep in sync (well in fact it whould break all chances to keep it in sync)

While I shall refrain from commenting on the discussion more widely, I should note that this objection is somewhat misplaced. It is rare in any event that I am able to merge code from Standard without making manual changes to adapt it to Experimental. Translation patches have come in the past which I have been able to deal with relatively easily, where necessary by performing a search and replace in MSVC++. Do not, therefore, abandon this project on account of 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.

Markohs

My guess was wrong then. Sorry. :)

prissi

I do not object improving it at times. But why changing a section that has not been touched for years?

And I am not a boss, the above was my personal view as anybody else. I will work whatever the majority decides. I am certainly not the most active coder anymore, so I am in no position to deny such things.

falconne

How about a wiki page with a glossary of common terms used and their translation? I currently keep Google Translate open on my second monitor; it would be easier to just have a page. Especially for German abbreviations that Google can't translate (I still haven't figured out what "besch" means) and variable names whose translation doesn't work worry well out of context.

I also think any kind of mass translation effort is not worth it and likely to break things, but it's definitely worth improving things bit by bit. Reading and understanding the code always takes a bit longer if you don't speak German, because the variables and methods don't register as well in your memory when you can't let your subconscious take care of it. Your brain's already trying hard to keep a lot of logic in immediate memory when you try to understand a complex piece of functionality, having to translate stuff in the middle of it breaks concentration and makes you forget bits.

Dwachs

About 'besch': I guess it is short for 'Beschreibung', in English = 'Description / Descriptor'.

My 2 pfeng on this subject:

Imho, it hurts more to have incorrect or ancient comments in the code. Also filenames should reflect, what is inside. (Btw: did you know in which file the code for the display settings window was? The file was named colors.cc, I only renamed it some weeks ago).

What about the following policy for future coding work:
* any routine that is change in one commit should get Doxygen-like documented in a follow-up commit
* any routine with German name should be translated to English in a follow-up commit. For consistency, also routines with similar purpose should be translated, too.
Parsley, sage, rosemary, and maggikraut.

dom700

As a native german speaker, I would like to point out that to me most of the comments / identifiers / classes are also sanskrit for me :) (or very good jokes, I love those comments)
If you would like to make it easier for people to work within the project, create a documentation file. Despite the (true) opinion that this project is well structured from karte onward, it's no good, if changing a hard coded variable takes an hour of looking for its location. It's especially problematic since this is typically the entry point for new people: changing a variable, changing a formula, whatever.

prissi

Quote
* any routine with German name should be translated to English in a follow-up commit. For consistency, also routines with similar purpose should be translated, too.
That is a lot of work and will lead to great chaos. Or I have to change all get_besch() haus_besch_t to building_desc_t and so on at once. Otherwise for powerline it would return get_desc() to get building_desc_t and for smoke get_besch() and smoke_besch_t. (Not to mention that also a lot of file names needs changes then too.)

I will comment whenever I add something beyond trivial and I comment new routines. But I do not think the gradual transition work.

If one really wants to do some cleanup codewise: Lets say on June 1st (example) we submit a patch that:
- makes karte_t static, call it map_t (shorten than world_t) and replace all welt-> by map_t:: That would reduce a lot of hassle with obtaining a welt pointer at many places while still keeping the relation between things.
- Change einstellungen_t to game_settings_t and umgebung_t to user_settings_t.
- grund_t to ground_t and boden to soil_t? (and bd
- haus* ti house*
- fabrik* to factory*
- strasse_t to street_t and so on
- change all besch to desc.
- Do a automatic reformat to proper space seperation and indentation (currently different ways in the code)
- change comments to proper style, remove author line (mostly wrong anyways and reworked by many)

It would of course break almost any patch. But if given the warning ahead we may decide for a month for just either integrate a patch or remove it. Any patch must be incorporated before (or will need a lot of work to have it again). Any then we have a clean slate, patchwise but also from programm styles and so on. It will require experimental also a lot of work to get to the same state.

Personally, for me it is rather this or leave it as it is, and only change gradual comments and new identifier. Imho anything in between just will add to confusion and make suffering worse. Oldtimer like me will not find the old names, newcomer will be confused why a car has auto_besch_t and vice versa.

jamespetts

#46
May I suggest some alternative translations for some of the variable names?

besch > type
haus > building

Do we also not need to translate "planquadrat_t", or is that not German to start with (it does not make a great deal of sense in English if it is intended to be English)? And "ribi" has been discussed before as being unclear - perhaps "direction_mask" or "dir_bits"?

There is also, I think, stadt_t (town_t) and stadtauto_t (privatecar_t), as well as a word beginning with "v" whose spelling I forget for pedestrians (pedestrian_t), and further vehikel_t (vehicle_t). Connected are the methods that generate pedestrians and city cars whose German spellings I forget, but that I suggest be named "generate_privatecars" and "generate_pedestrians" respectively.

Also, there are the various "bauer" classes (tunnelbauer, and so forth) that could translate to, e.g., "tunnelbuilder_t". I think that bridges, too, are still "brucke" in the code.
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.

DirrrtyDirk

Quote from: jamespetts on January 13, 2012, 01:21:41 PM
Do we also not need to translate "planquadrat_t", or is that not German to start with

It is german. You could translate it as (map) grid (square) or so. That language question being solved (hopefully), I'll leave you Dev guys alone again.  ;)
  
***** PAK128 Dev Team - semi-retired*****

jamespetts

gridsquare_t seems easy to understand.
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.

prissi

There is many more stuff. ANd of course we should discuss before what to choose.

But type is imho not a good translation for the description of an object, since type is already another fixed term in programming. "Overloading" that with a different meaning sound not like progress. The same would apply for definition. Although personally house_def_t sounds not too bad. (I would not use too long names, as during programming you have to type them too.)

If karte_t goes to map_t then planquadrat_t make rather sense as map_square_t to me.

But of course I am german. And the choosing of names should be neither british nor american, canadian but internationally compatible.

isidoro

Imho, some translations are not worth the effort.  For instance, vehikel -> vehicle, karte_t -> map_t, hous -> house, fabrik -> factory, strasse -> street, since the German term resembles the English one and is not a problem when reading the code.  And it even looks cool and reminds the origin of the code.

However, besch -> desc, bauer -> builder, einstellungen, direction, etc. is much needed.


TurfIt

#51
Quote from: prissi on January 13, 2012, 12:47:57 PM
Personally, for me it is rather this or leave it as it is, and only change gradual comments and new identifier. Imho anything in between just will add to confusion and make suffering worse.
Staying the course with the gradual changes is the only thing that makes sense. Maintains compatibility not only with the outstanding patches, but with the current contributors too. I truly don't see there being a lineup of people ready to jump into the code, but for all that German keeping them away...

I'm not German. My knowledge of the language doesn't exceed that which is overheard at Oktoberfest... In fact I'm currently quite uni-lingual having lost the minimal French from childhood. The presence of German in the code has not been a hindrance at all in getting to the level of familiarity I now have with the code.

planquadrat_t, gridsquare_t, or map_square_t, wouldn't have mattered when initially starting out with the code. Now, it demonstrates perfectly the problem. What is the correct word choice? I've already picked *my* choices and they're now seared into the mind forming a mental map of the code. If something different from what I've been using is chosen, extreme confusion. I don't think I could make that mental leap to update my map wholesale. Which really means relearning everything from scratch. Frankly, I don't think I have the desire to do so.


EDIT:
Just ran across a very applicable quote:
http://developers.slashdot.org/comments.pl?sid=2619084&cid=38684742
QuoteAs for dealing with other people undocumented code, that's just a skill you need to have as an engineer, like being fluent in multiple languages many of which won't be your choice. You think I want this tool chain to be written in TCL? Should I then port it to my favourite language (e.g. perl) what if the next poerson to support it prefers python? It's just part of engineering that everyone else's code will look rubbish and undocumented to you. Even when it is documented you'll then think the documentation is overkill.
Undocumented or documented in a foreign language, close to the same thing. Suck it up and deal.

sdog

being used to fortran, i'm a bit amused that the language of variables causes difficulties ;)

if a translation really is desired, couldn't perhaps instead of searching and replacing a very robust perl or python or awk script be used. This should also be applied to work in progress versions and patches, to address the issue TurfIt mentioned and conversion of experimental.



(i've difficulties reading c on the level used in simutrans, so please disregard my comment if it is not helpful)

Combuijs

QuoteUndocumented or documented in a foreign language, close to the same thing. Suck it up and deal.

That is where I absolutely disagree. Undocumented code is far better understandable if the variable and type names are understandable (and chosen rightly...) . Otherwise you could just number your classes c1 to cn, number your variables v1 to vn and number your types t1 to tn. The code is then doing exactly the same, but it takes a lot of time to be understandable.

Documentation (or classes, variables, types) in a foreign language does not help if you don't know what they mean.

As for an example a C# code extract in Dutch (from my own software) stripped of commentary. I bet that a Dutchman will analyse the code twice as fast as an Englishman, just because he understands what the variables will do.

        private string NaamVolgensTaalRegel()
        {
            string NieuweNaam = "";
            char[] Separators = new char[2];
            Separators[0] = '[';
            Separators[1] = ']';
            string[] ParseStrings = mNaamTaalRegel.Split(Separators);
            bool ZeHoudtVanMe = true;
            for (int i = 0; i < ParseStrings.Length; i++)
            {
                string Part = ParseStrings[i];
                if (Part != "")
                {
                    if (ZeHoudtVanMe)
                    {
                        NieuweNaam = NieuweNaam + Part;
                    }
                    else
                    {
                        DhItem Item = ItemsIncompleet[Part];
                        if (Item != null)
                        {
                            object Waarde = Item.Waarde;
                            if (Waarde == null)
                            {
                                Waarde = Item.DefaultWaarde;
                            }
                            if (Waarde == null)
                            {
                                Waarde = Item.ForfaitaireWaarde;
                            }
                            if (Waarde != null)
                            {
                                NieuweNaam = NieuweNaam + DhWaarde.WaardeToString(Item.WaardeType, Waarde);
                            }
                        }
                    }
                }
                ZeHoudtVanMe = !ZeHoudtVanMe;
            }
            return NieuweNaam;
        }

Bob Marley: No woman, no cry

Programmer: No user, no bugs



prissi

Stripping comments is never great, no matter what language. And I think that nobody disagreed about changing and adding comments.

Actually, the only very little was unclear in your example due to language:
ZeHoudtVanMe (should get a comment anyway) Google said this mean They love me ... with such a variable name I would not be so sure ;)
NaamVolgensTaalRegel (But such a "long" function should get a comment anyway)
That is all that might not be obvious by not speaking Dutch.

And without definition of DHItem  (anyway that is not really dutch, just letters ... ), object (what a name for a type!) and the type of mNaamTaalRegel one cannot guess really the meaning anyway, as with C++ and overloading of operators all strange stuff could happen.  ;)

Spike

In the terminology of some Java teacher the besch* classes would go as "catalog like descriptions" for  objects which all share the same properties.

Well, not only Java: http://en.wikipedia.org/wiki/UML_colors

Quote
description — Is it simply a catalog-like description which classifies or 'labels' an object? If users of a system are labeled based on the department of a company they work within and this doesn't change the way the system behaves, this would be a description.

-> desc  ;)

Combuijs

QuoteZeHoudtVanMe (should get a comment anyway) Google said this mean They love me ... with such a variable name I would not be so sure ;)

It actually means "She loves me"... (Note that the variable alternates between true and false: She loves me, she does not love me, she loves me, etc..., I wonder if they play that flower petal game outside the Netherlands too...  ;D ).

Quoteobject (what a name for a type!)

That's actually the C# equivalent of C's void*.
Bob Marley: No woman, no cry

Programmer: No user, no bugs



Isaac Eiland-Hall

#57
Quote from: TurfIt on January 13, 2012, 04:41:35 PM
I truly don't see there being a lineup of people ready to jump into the code, but for all that German keeping them away...

EDIT: I'm one person, but probably very unimportant. (previously wrote way too much to say just that). And maybe I put too much important on not understanding terms when I tried. :)

Quote from: Combuijs on January 13, 2012, 10:08:41 PM
She loves me, she does not love me,

Same game in English is phrased "She loves me. She loves me not." (etc.) - pulling petals off the flower, and the last petal represents the "true" answer, surely the same.


Ashley

From my relatively little experience of the code base the German words are definitely the last thing I'd spend time refactoring out. I agree with Prissi about consistency being more important. Learning what umgebung and planquadrat mean is fairly easy in comparison with working out what's going on overall, and working that out is made miles easier through consistent documentation (in German or English - google translate is pretty good for German-English translation!) and consistent coding standards.

IMO ofc.
Use Firefox? Interested in IPv6? Try SixOrNot the IPv6 status indicator for Firefox.
Why not try playing Simutrans online? See the Game Servers board for details.

isidoro

This is what I get from Google Translate for these two sentences in German:
QuoteDies ist der x-Offset in Bilschirmkoordinaten bei der Darstellung des Objektbildes. Dies ist die Koordinate des Planquadrates in der Karte zu dem das Objekt gehört.

QuoteThis is offset in the x-Bilschirmkoordinaten in the representation of the object image. This is the coordinate of the square in the map plan to which the object belongs.

What plan?  What Bilschir...?  Those sentences make no sense.

And those are not the worst cases I've found while visiting the code...  But you are right, if Google Translate works that nice from German to English, it will probably work the same from English to German, won't it?  Please, document in English at least...

I've been directly working with the code not farther than a month from now.  I've got no idea of what does umgebung means now.  A casual developer, and those are not to be neglected in an open source project due to lack of resources, may program by reading similar sections of the code he tries to implement and imitate them.  That's nearly impossible with code written in a foreign language.  I don't understand a word of Combujis' flower example.  If written in English, I would have understood it quickly and at once.

I am not a native English speaker.  I don't like the present state of things, but I don't understand why what is of application for the International Simutrans Forum, by a magic twist, is not applicable to the code of the program.  Let's speak German here, if all your argument is right.  Either that or rename the forum to the English Simutrans Forum...

P.S.: if I were a native English speaker, I wouldn't probably like things as they are.  English is by far the worst treated languages of all by non-native speakers like me.  I wouldn't like that to be done to my language either...  But they worked hard to achieve it...


sdog

#60

here are some translations for you:

the first is just a typo: Bildschirm means screen


planquadrat is not well translated by google, it is a square of a map grid


umgebung is the set of points with a distance smaller than a set limit.
most likely you know an epsilon-umgebung form school (the german word is often used in english textbooks afaik)




p.s.: (off topic)
"English is by far the worst treated languages of all by non-native speakers like me."
i'd not be so sure, my experience with marking undergraduate's texts in canada is that non-native speakers are much more likely to deliver something readable than native speakers. the errors in grammar are also typically less severe than those of native speakers, spelling is very rarely wrong with non-native speakers.
I should rather say, native speakers work hard enough themselves to mistreat their language.

isidoro

Quote from: sdog on February 10, 2012, 12:27:43 AM
[...]
"English is by far the worst treated languages of all by non-native speakers like me."
i'd not be so sure, my experience with marking undergraduate's texts in canada
[...]

Touché!  :)

IgorEliezer

I could say:

       
  • It seems there's a consensus that, a code in English would make the Simutrans source code more inviting for new coders. (It's already attracting new people)
  • It seems there's a consensus that, a translation is or will be necessary.
  • But, there's no consensus the code should be fully translated now. Some developers might or could "lose the track" if it happens.
  • Nonetheless, some few people think that something should be done, from now on.
Then, my conclusion:
The translation is necessary, we agree with it; but we haven't decided about "when and how" to do that. I would propose the developers could choose what parts or elements of the code could be translated. People translate these parts and summit. Once incorporated into the code, the developers choose other elements of the code, and so on, until full completion.

sdog

i don't think there is anyone in this thread against translating comments, what isidoro posted was obviously a comment. this a little different from translating the source code and is better kept distinct in the discussion.

(got only involved in the thread as i thought isidoro needed translations, as i'm no coder, i have and want no say.)

Dwachs

Quote from: sdog on February 10, 2012, 12:27:43 AM
umgebung is the set of points with a distance smaller than a set limit.
most likely you know an epsilon-umgebung form school (the german word is often used in english textbooks afaik)
rofl Let epsilon be so small such that epsilon/2 is already negative ^^

umgebung_t should be translated to environment: all settings that can be changed without an effect on the simulation, ie these settings only change the look & feel of the program but not the behavior of the game simulation.

My 2 cents on this topic: Why not develop a script that does the translation? Then patches and forks of simutrans-standard can be translated much easier. Merging changes where every line changed is not fun. And I would suggest to do it piece by piece: the besch system, the gui, ding_t 's etc.
Parsley, sage, rosemary, and maggikraut.

Spike

I have started to translate identifiers in my "Simutrans Iron Bite" branch. It's been part of what I considered to be important:

http://forum.simutrans.com/index.php?board=99.0

I started with some type and method names. But it will take time to translate everything. At the moment I have no scripts for this yet, though, I do it manually.

Dwachs

Quote from: Memzeron on February 10, 2012, 09:28:37 AM
I have started to translate identifiers in my "Simutrans Iron Bite" branch. It's been part of what I considered to be important:
Which is a bad idea imho, as it makes it unnecessarily difficult to produce patches to transfer work on new features into simutrans-standard.
Parsley, sage, rosemary, and maggikraut.

Spike

I guess I make myselve unloved this way, but it is intentional that my changes are hard to merge back. You have refused to let me work with you on Standard, I got no direct access to change the code, and I was told my changes are unwished/unliked.

So I do my own thing with my ideas and if you should change your mind and consider my changes good some day, I want that you have it really hard to get them back into Standard.

omikron

Welcome to the kindergarden....

Do you think you achieve anything this way, Memzeron?

Spike

#69
Yes.

1) I achieve control over my development line. I'm tired of all this arguing if my ideas are good and bad. On my branch I can just go and do it.

2) I don't like how I was/am excluded from main development. I shall make patches and wait days for them to be include? Never. If they exclude me, I exclude them. I had tried to get into the team, but wasn't allowed. Why should I support people who have declared not to want my changes in the first place?

3) I think I am a competent coder (No, that doesn't mean best programmer of the world. Just someone who knows what he does, and who has many years of experience in the field). I will try to outperform Prissi and Dwachs by providing a better code base, and attract patch makers and developers to my code base, because they can read it better and develop quicker with my code. At the moment my code compiles quicker, that saves each developer some minutes for each full build already. And I achieved that in only a few days.

*shrugs*

But hey, why should I care at all? Dwachs and Prissi don't like me and my ideas either, and the discussion about that took way too long. So I'll do my own thing from now. It's unimportant to me what they think or do, if they have it easy or not - I believe that I have good reasons for my decisions (about what is good in coding, and about good UI design), and I'll do what I consider the right thing to do. Why should I bother with people who have different ideas, and think they are right with their ideas? We'll never get together anyways.

See how long it took to discuss if german is bad in the code? Now that I've started my branch, and translated some identiefiers, suddenly Dwachs wants to translate, too. Before that eveyone was against translating the code becase of reasons bla and blubb. Heh. I know it's good to have English code since most developers can read it. So I don't need to discuss that with anybody, I just need to do the translation.

kthnxbye.