News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

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.

sdog

QuoteThat would be a global constant, which I have never understood to be a problem.
But then it'd have to be set at compile time, not passed as parameter at program start.

Ters

Quote from: sdog on September 21, 2013, 09:33:48 PM
But then it'd have to be set at compile time, not passed as parameter at program start.

In C/C++ atleast, parameters passed to the program at runtime would have to be parsed from the command line and into a variable. At this point, global constants have long since been locked to their values. In C++ and later versions of C, one can create constants later in the program flow, but such constants are scoped to the function creating them, so no other function can know about them or their value. The value itself must be passed explicitly as a parameter to all functions that need to know the value, though any intermediate function as well. (C++ has a concept called functors/function objects, which behaves somewhat differently, but I won't try to explain that now.)

isidoro

Another problem with globals, even if constant, is that your global namespace gets dirty.  You never know if some name is already taken somewhere else.  Moreover, the global name can be obscured by a local variable with the same name and that can get unnoticed, with undesired side-effects, or two different people on the same project can choose the same name for different purposes in their branches, or...  And that problem is shared with global functions.

Quote from: Markohs on September 21, 2013, 12:03:49 PM
[...]
I think you guys would completely hate programming java. :)

I do!  I don't understand people that like it so much.  Not to mention Fortran.  It was a real pain when I had to work with that "language".

Quote from: kierongreen on September 21, 2013, 03:29:33 PM
[...]
About IDEs - some people don't use them. I don't for one.
[..]

With me, we are two...   ;)   I find them too uncomfortable to use.  And pretty slow.  And you lose half an hour to find easy things, hidden in menus, like where to set command line arguments in Visual Studio.

Some of the thoughts I have seen in this thread are just a matter of personal choice (some are just false: Fortran is 20 years older than C, for instance), even if they are quite widespread.

My advice is that you choose the options that make programming more comfortable for the majority of developers.  Some people like to wear ties, some other think that wearing ties is a must, but if you feel more comfortable wearing just a t-shirt, do it!

Ters

Quote from: isidoro on September 22, 2013, 12:44:58 AM
I do!  I don't understand people that like it so much.
[...]
With me, we are two...   ;)   I find them too uncomfortable to use.  And pretty slow.  And you lose half an hour to find easy things, hidden in menus, like where to set command line arguments in Visual Studio.

The key to liking Java for me was IDEs. After learning a handful of hotkeys, less than I've seen some people use in Simutrans, they write much (but not most) of the code for me. The ease of which one can start using a library in a project is also miles apart from C/C++, or pretty much any language I know of, except those languages that also run on the Java platform. (Although I suspect this leads to more breeches of open source licenses than would otherwise be the case.)

So the strength of Java isn't so much the language in itself (although I guess the lack of a preprocessor makes it easier for IDEs to understand the code), but the ecosystem around it. Some have found the Java language itself less than ideal, and have made other languages that run on the Java plaform and therefore can take advantage of the established ecosystem.

TurfIt

Can we *STOP* with these piecemeal translations...
If you're so hellbent on this useless endeavour - do it all at once. Completely. Then never again.
Completely - WTF does 'dt' stand for in 'obj_t *dt =' ?      'ding_t *dt = ' - atleast made sense...
Best guess it'll now take me 8 hours of wasted time to merge in what I've been working on. And once done, just in time for another commit completely breaking things again; All for absolutely no gain, no new features added, no bugs fixed. Nothing. I'd rather spend my time working on something useful, this isn't it.

kierongreen

I thought we'd decided now was the time for translating? No?

Ters

There is a gain. A huge fraction of the Earth developers won't have to run the code through Google translate (or flip through a dictionary) to understand the Simutrans source code. But I agree that translations should be applied to trunk in as few commits as possible, at points where all other major projects has a chance to be prepared for it and don't have lots of work ready for committing. We can't save stale patches that are just lying around, they're likely broken by the big changes done to karte_t and the GUI anyway, but at least give the active projects time to synchronize.

(Reminds me of a day at work a few weeks ago, where one of my colleagues spent half a day trying to commit, but every time he managed to merge the latest changes on trunk into the code he was about to submit, someone else had committed a new changelist which necessitated a new merge operation.)

kierongreen

My thoughts were to get the BIG translations (ding to obj, besch to desc) out the way quickly as these affect most files in the game. Smaller ones such as bruecke to bridge while still involving lots of code lines are at least limited to a smaller number of files.

Ters

Quote from: kierongreen on September 22, 2013, 05:06:31 PM
My thoughts were to get the BIG translations (ding to obj, besch to desc) out the way quickly as these affect most files in the game. Smaller ones such as bruecke to bridge while still involving lots of code lines are at least limited to a smaller number of files.

That's a good plan, but not so quickly that others can't prepare for it. Especially as central developers as TurfIt.

Markohs

#219
Wait, Turfit, I have one last change coming, environment->env, as was required by prissi.

Commiting it soon, and no more changes from me.

EDIT: I see prissi already changed it, so never mind. The file was not renamed, but well, let's let this stay as it is.

kierongreen

Environment to env has already been changed!

Markohs

yes, I saw now, I was just about to change it myself now. ;)

No changes from me then.

kierongreen

I'm tracking down all ding (also dt, d etc) variables renaming them to obj (or similar e.g. new_obj).

prissi

Originally those changes should be done directly after a release. I ratehr would not like them now, as TrufIt wrote. But then, now we are anyway very far from a release ...

An_dz

#224
I did not followed the comments discussion. But I made some changes in dataobj folder.

Edit:
Patches for bauer, display and ifc folder.

kierongreen

Many thanks committed dataobj.diff, bauer.diff, display.diff and ifc.diff to trunk revision 6825.

An_dz

Then here are patches for everything but gui and besch

kierongreen

#227
Eeek that's quite a lot might take a while to look through those! :)

Ok a few comments, there's quite a few examples in these patches of hyphenation being added to words perhaps unnecessarily. For example reestablish to re-establish, reentrant to re-entrant, reseted to re-setted (which could actually just be reset). I also note that it's not just in your patches for example there's exisiting comments such as un-reserve in the code already.

Now in the lot of patches I just committed I just put these hyphenations in since they mostly seemed to be fairly unusual words where I could see it might help people understand the meaning. I'd like some opinions, particularly from non-native speakers of English as to what they find clearest.

Ters

Like Germans, I'm used to bunching words together into infinitely long strings of letters. The only difference is that the original words tend to be shorter than the German equivalent. So I'm used to reading without hyphens or (an abundance of) spaces.

An_dz

A patch to fix all typos you guys made from r6864 to r6922.

IgorEliezer

Quote from: An_dz on November 25, 2013, 07:51:35 PM
A patch to fix all typos you guys made from r6864 to r6922.
I see what you did there! :E

An_dz

Two patches to fix some typos.

One for history and simuconf.tab, and another for new typos brought between r6969 and r6972, it's only on grund_besch.cc and brueckenbauer.cc.
I also included a comment on brueckenbauer.cc to explain one error message.

And have anyone finished reviewing the last one? (r6864-r6922)

jamespetts

Apologies for necroposting, but I thought that it might in this instance be preferable to starting a new thread on the same topic.

I wonder whether it might be time to make more progress on this project? There are still quite a lot of untranslated variable/class/function/file names in Simutrans, and this may well be putting off new contributors. Indeed, a prospective contributor to Simutrans-Experimental has recently described the large amount of German in the code as "daunting", although he tells me that, happily, he still intends to work on the project.

I really do not want to have different variable/class names in Standard than Experimental, however, as it would make merging much harder, and I do not think it helpful to developers of either if the code-bases drift apart in non-functional ways. If I were to set myself up to compile Standard and produce some more translation patches, would there be a good chance of these being accepted?

Some of the names that I consider are in a high priority to translate are (with suggested alternatives in brackets following):

       
  • convoi (convoy)
  • besch (base_type)
  • grund (ground
  • bild (image - this has already been translated in some places, but remains in others)
  • eintrag (entry)
  • fahrplan (shcedule - only the filenames need renaming, I think)
  • fussgaenger_besch_t (pedestrian_base_type_t)
  • gebaeude (building)
  • stadt (city)
  • fabrik (industry)
  • fundament (foundation)
  • planquadrat (ground_tile)
  • platzsucher (location_finder)
  • simfab (simindustry)
  • ware (cargo)
  • warenzeil (cargo_destination)
  • wasser (water)
  • zeiger (pointer)
  • raucher (smoke_producer)
  • vehikel (vehicle)
  • bauer (builder)
  • boden (ground)
  • linien (line)
  • eintrag (entry)
  • schiene (railway)
  • strasse (road)
  • bauigel (constructor)
  • route_fuer (route_for)
  • ist_doppel (is_double)
  • ribi (direction_bits - I know that this is longer, but it makes what this is about so much clearer)
  • ist_einfach (is simple)
  • ist_wegbar (is_pathable)
  • ow (ew)
  • ost (east)
  • nord (north)
  • sued (south)
  • laden (load)
  • alle (all)
  • doppelr (double)
  • rueckwaerts (backwards)
  • exakt_orthogonal (exact_orthagonal)
  • ist_ (is_)
  • einfach (simple)
  • kurve (curve)
  • gerade (just)
  • hang (slope)
  • optionen (options)
  • kennfarbe (colour)
  • farbengui_t (colour_gui_t)
  • haus (structure - this cannot also be "building")
  • kanal (canal)
  • karte (map)
  • liefere_an (suppy)
  • starte_mit_route (start_with_route)
  • hole_ab (unload)
  • get_ware_fuer_zielpos (get_cargo_for_destination_pos)
  • get_ware_summe (get_cargo_amount)
  • liefere_an_fabrik (deliver_to_factory)
  • sortierung (sorting)
  • welt (world)
  • koord (coord)
  • haltestellen (stops)
  • haltestelle (stop)
  • verbrauch (consumption)
  • anzahl (number)
  • kapazitaet (capacity)
  • platzierung (placement)
  • produktivitaet (productivity)
  • bereich (range)
  • gewichtung (chance)
  • lieferanten (suppliers)
  • produkte (products)
  • rauch (smoke)
  • fab (ind)
  • verteile (distribution)
  • ausgang (exit)
  • eingang (entry)
  • vorrat_an (stockpile)
  • fpl (sch)
  • baue (build)
  • hierarchie (chain)
  • zufallsbauplatz (random_building)
  • finde (find)
  • sucher (search)
  • hersteller (producer)
  • bauplatz (place_to_build)
  • spezial (special)
  • bau (build)
  • bewerte (check_value - I am not sure about this translation)
  • wachstum (growth
  • zufallspunkt (random_point)
  • arbeiterziel (workplace)
  • senke (sink)
  • pumpe (source)
  • linksoben (top_left)
  • rechtsunten (bottom_right)
  • lo (tl)
  • ur (br)
  • bruecke (bridge)
  • baum (tree)
Despite the length of the list, I have probably missed quite a few. As far as I can see, all of these can be refactored with a simple search/replace (provided that all superset strings are searched/replaced before all of their subsets).

Would a patch containing such replacements (or multiple patches containing fragments of them at a time) be acceptable? Would anyone like to propose a better translation for any of my suggestions above?

The next project after that would be translating the remaining code comments, but the class/file/variable/function names seem more important.
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.

TurfIt


jamespetts

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.

Ters

Quote from: jamespetts on November 15, 2016, 02:18:07 AM
What is the difference?

Everything, except that they have to do with transportation. The convoi used in Simutrans is also apparently not a German word, but a French. The German word for convoy is Konvoi. And even the French word is apparently incorrectly used. (Although the phrase "convoi exceptionnel" seems a special case that would fit, but that special case does not exist in Simutrans either.)

There are no convoys in Simutrans! The closest you get is a congestion.

jamespetts

Perhaps, then, "assemblage"?
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.

DrSuperGood

Quoteconvoi != convoy.
I always thought it represented "convoy" because the object consists of a whole lot of individual transport units following each other like a convoy.

Maybe suggest an alternative? The type names should be clear English and not made up or borrowed from other language words.

Quote
simfab (simindustry)
I thought it was short for sim fabrik which should be "simfactory". Although I guess industry is also a valid alternative.

An_dz

Quote from: DrSuperGood on November 15, 2016, 02:36:27 PM
The type names should be clear English and not made up or borrowed from other language words.
Is that not the definition of language? :D ;) Even more with English.

jamespetts

Other than the issue with "convoy", is everyone happy with the suggested search/replace alternatives suggested above? If "convoi" were to go to "assemblage", all "cnv" local variables would have to change to "****" or similar.
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.

Tjoeker

But isn't a convoy in English a set of vehicles bound together?

Edit:
See, if I look up convoy in google I get this:



Ters

Some of these words are hard to translate out of context. I would expect "gerade" to mean "straight". "schiene" is probably "track" as in "railway track", rather than "railway", which I imagine to be more broader in scope. "pathable" seems like a very artificial word to me. I think "sucher" is "searcher", rather than "search", but "finder" might be a more established term in software development. Isn't "building site", or "construction site", a more natural term than "place to build"? "Calculate value" seems a more correct translation of "bewerte" in general than "check value".

Vladki

I think that convoy is the right translation of Konvoi or convoi. The problem is that the term is used differently in simutrans than in real world. In simutrans it is used to mean train, or its equivalent for road or water transport. So "train" could be as well used as translation, but I think that most developers and also player are already used to the modified meaning of convoy in simutrans.

prissi

Quoteconvoi (consist)
besch (desc) from description or (prop) from properties
...
planquadrat (tile)
...
ware (cargo) well passengers, mail and nothign are hardly cargo ... but for a lack of better word ...
...
zeiger (indicator) pointer usually means something else in computer-lingo ...
raucher (smoker)
...
boden (soil) You cannot have to thing which are "ground"
...
schiene (track) as this type is the foundation for any track-based transport
,,
bauigel (constructor)
...
ist_doppel (is_twoway)
ribi is not a german word, so I would keep it anyway ...
ist_einfach (is_oneway)
ist_wegbar (is_driveable)
...
laden (loading)
...
doppelr (double_ribi)
rueckwaerts (get_backwards)
exakt_orthogonal (exact_orthagonal)
ist_ (is_)
einfach (simple)
kurve (bend)
gerade (straight)
hang (slope does not work, there is a slope type already
optionen (option_frame_t)
kennfarbe (industry_color) do not find it elsewhere
farbengui_t (colour_gui_t)
haus (building_structure - this cannot also be "building")
kanal (waterway)
karte (map) not possible, map is used too
liefere_an (suppy_to)
starte_mit_route (start_with_route)
hole_ab (load_from) (but depends on context)
...
sortierung (sort)
welt (world) is mostly done already
koord (coord) has been done too
haltestellen (stop_list)
...
ausgang (outgoing)
eingang (incoming)
...
fpl (sched)
...
bewerte (rank)
...
senke (drain)
pumpe (source) (but I think they are already converted)
...

Quite some suggestions have been done already.

Ters

"sink" is probably a more common term than "drain" in the context of simulation.