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 2 Guests are viewing this topic.

Vladki

Quoteist_doppel (is_twoway)
ribi is not a german word, so I would keep it anyway ...
ist_einfach (is_oneway)
ist_wegbar (is_driveable)

Have a look at dataobj/ribi.h and class hang_t:
// wegbar: flat enough for ways, infach=only one ew/ns direction, doppel=two height difference

isidoro

I think that some of the word are more urgent that others.  It doesn't matter whether you write convoi, konvoi, convoy, assemblage, etc., an English speaker can easily guess the meaning.  I would leave it like it is, with its short form (cnv).

Just the opposite with wachstum (growth), anzahl (number), baum (tree), to name only a few.  Those are really the most urgent to translate.  If you are German, Nordic, or even English, maybe you find those German terms familiar, but for non northern language speakers, they are a total mystery when reading the code.

jamespetts

#247
Thank you for all the feedback. It would be good to unify the language of variables/functions/classes/files once and for all. Prissi - thank you for copying that list, and apologies for not having noticed it. Do I understand that you are content with all of the terms set out in it, or would you propose any modifications to it? The next step would seem to me to be to produce a combined list with the best of the original suggestions and my suggestions and try to get consensus (within reason) as to the optimum replacement word in each case. The sooner that we get this done, I think, the sooner that we will have an increased likelihood of new developers working on the code in both Standard and Experimental, which will benefit the whole community.

Edit: Another translation that we probably need and should be easy: get_zeit_ms should become get_ticks.
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, 11:47:02 PM
Edit: Another translation that we probably need and should be easy: get_zeit_ms should become get_ticks.

In my experience, ticks and milliseconds are not usually the same. "get_time_ms" would be a better translation, assuming the get_zeit_ms function does what I think it does; I don't have any context for it.

Tjoeker

as far as I know, get_zeit_ms gives you the number of ticks that passed by since the new month started.
So get_ticks seems good to me.
However, get_time might explain a bit easier what it does?

jamespetts

The actual function just returns the value of a variable called "ticks", so get_ticks would follow the normal convention.
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

Many of the method comments need to be rewritten, or even written to start with. Some of them are not very helpful as to explaining the purpose or functionality of a method.

jamespetts

The comments can perhaps wait until the more urgent re-naming task is done. Comments may be better written by those with a more intimate knowledge of the whole code than I.
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: Tjoeker on November 16, 2016, 07:31:16 AM
as far as I know, get_zeit_ms gives you the number of ticks that passed by since the new month started.
So get_ticks seems good to me.
However, get_time might explain a bit easier what it does?

Quote from: jamespetts on November 16, 2016, 07:40:44 AM
The actual function just returns the value of a variable called "ticks", so get_ticks would follow the normal convention.

That just shows how wrong things can get if one considers names without the context, like with just the massive lists. I tried to find get_zeit_ms, but couldn't find it.

jamespetts

#254
Is this one whose name has changed in Standard and not caught up in Experimental, or have I got the e and the i the wrong way around again?

Edit: We also need, I think:


       
  • vorgaenger (leader); and
  • nachfolger (follower).
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.

Dwachs

This is still there in simworld.h

uint32 get_zeit_ms() const { return ticks; }
Parsley, sage, rosemary, and maggikraut.

jamespetts

Yes, that was what I was referring to.
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: Dwachs on November 17, 2016, 01:09:31 PM
This is still there in simworld.h

uint32 get_zeit_ms() const { return ticks; }


I was looking in various simsys files and then simmain, because that was where I expected a function returning the time in milliseconds to be. It was only later revealed that the name was misleading.

prissi

Also leader and follower is not very good translation. Rather "leading" and "trailing" seems better, as it describe a function (which is the purpose of verbs).

Dwachs

Here is a translation of ribi.h . Please check if this is understandable. What is the correct expression for 'non-straight way'? bend? curve? What would be the corresponding bool function: is_curve(d) / is_bend(t) ?
Parsley, sage, rosemary, and maggikraut.

Vladki

I would prefer bend. But that's just because curve sounds too close to one (not only) czech insult ;)

Ters

Quote from: prissi on November 17, 2016, 10:26:53 PM
Also leader and follower is not very good translation. Rather "leading" and "trailing" seems better, as it describe a function (which is the purpose of verbs).

But are verbs the right to use here? It seems natural to me that types and variables are nouns (or sometimes noun phrases), while functions are verbs or (perhaps some would say unfortunately) more commonly verb phrases, both in the imperative mood. "Leading" and "trailing" can also be seen as verbal adjectives, though, and adjectives are common in enums or similar constants.

The comments always use the full term "leading vehicle" and "trailing vehicle", except in case which uses "trailer". But I'm not so certain these terms are quite correct, especially the first one. When I hear or read "leading vehicle", I think of the foremost vehicle, but that is not the case here. Perhaps "preceeding vehicle" is better? If using an IDE with good auto-completion, especially one that understands initials, I would not hesitate to use more than one word for this. In my Pak Explorer, I've called these fields "numPossibleBefore" and "numPossibleAfter".

isidoro

Quote from: Dwachs on November 18, 2016, 08:44:13 PM
Here is a translation of ribi.h . Please check if this is understandable. What is the correct expression for 'non-straight way'? bend? curve? What would be the corresponding bool function: is_curve(d) / is_bend(t) ?

Good for me, except for line 209:
Quote   static ribi rueckwaerts(ribi x) { return rwr[x]; }

Another question: why not change defines in lines 44-47 and lines 111-114 so that if corner1 is swcorner it's named like that?
Quote
#define sw_corner(i) (i%3)        // sw corner
#define se_corner(i) ((i/3)%3)    // se corner
#define ne_corner(i) ((i/9)%3)    // ne corner
#define nw_corner(i) (i/27)       // nw corner


I don't know which would be better, curve or bend.

jamespetts

Briefly: I think that Prissi is correct about leading/trailing, and that Isidoro's suggestion to use "corner" in the manner that he suggests is sensible.
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.

kierongreen

In English generally roads have bends (or corners if particularly sharp), and railways have curves. Though they can be used interchangeably so take your pick!

Dwachs

#265
Committed the ribi translation with r7947. Translated also north/south/east and related directions.

I added some bash script files for doing these automatically in translate_code/. Call the script like this

./batch_replace translate_nsew.csv

the parameter is a comma-separated list of translations: original,translated.

The next step would be to translate the files in grund/. Here I have some questions regarding translation:

  • grund_t -> tile_t - this is the base class. I would prefer a short name.
  • boden_t -> soil_t ? These are tiles that  contain ways, trees, no buildings. How to call them?
  • halt -> stop ?? I do not like this. But it seems to be the correct English word?
  • karten_boden -> ground or surface? These are the tiles at the surface of the earth.
  • natur -> empty
  • planquadrat -> grid_square or map_square?
  • wasser -> water or sea?
  • *_nr -> *_no  There are many member variables that store an index (image number etc). What would be correct abbreviation? bild_nr -> image_no?

Edit: renamed fahrplan.* -> schedule.*, linieneintrag.h -> schedule_entry.h
Parsley, sage, rosemary, and maggikraut.

kierongreen

In my opinion nr works as an abbreviation for number I wouldn't see a need to change it. wasser to water and grund to ground make sense to me. halt could stay as is. boden I would say could become tile. karten_boden could become landscape? natur to empty seems good, planquadrat to grid_square seems better option I think.

Vladki

grid_square and tile seem a synonym to me (for planquadrat). I think boden should be translated as base, bootom, land, terrain or such

prissi

Tile is rather the planquadrat_t or grund_t ... (map_square_t or mabe really grid_square_t could be another take at planquadrat).

I would rather see grund_t is a general tile_t and boden_t becomes ground_t. THen kartenboden could become map_ground_t ...


Dwachs

what about

  • grund_t -> tile_t (base type, short name)
  • boden_t -> ground_t (some tile with green gras)
  • karten_boden -> surface (after all, these are the tiles precisely at the surface)
  • planquadrat -> grid_square
@Vladki: planquadrat is the class that holds a list/stack of all tiles at the same (x,y) position

Next question, much more difficult ;)  How to translate *_besch_t ?  The more I think about it, the more I like *_type_t. building_type_t etc looks good. Other proposals were: desc (descriptor - I used this for the squirrel interface), and prop (for properties).
Parsley, sage, rosemary, and maggikraut.

jamespetts

All splendid ideas. As to *_besch_t, I am not a fan of *_type_t as the trailing "t" also stands for "type", so there is an element of redundancy. "Base", perhaps?
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

Quote
All splendid ideas. As to *_besch_t, I am not a fan of *_type_t as the trailing "t" also stands for "type", so there is an element of redundancy. "Base", perhaps?
The _t suffix represents a type name, as opposed to a variable or other sort of name, with regard to programming in C/C++. Hence type_t is not redundant as it is a C/C++ type called type. Type ultimately best describes what the object is.

In games like StarCraft II all data is managed using XML databases. There each type of data is described as a scope with instances of a scope being referred to as entries. If such a naming approach was adopted it would make it *_scope_t. If this is more readable/sensible than *_type_t is questionable.


Ters

I lean towards desc over type, because not all of these things are strictly speaking types (beyond what the _t suffix represents). A type is usually made up be several such nodes, and a few skins don't really represent any kind of type at all. That desc has been used in parts of the code also gives some precedent. The directory containing them should called descriptors, to make the meaning clear.

jamespetts

The idea of using an unabbreviated directory name to make the abbreviated type names clear is a good one.
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

Also some objects already have a type (which is a uint8), so another get_type() returning a former besch * will add confusion ...

DrSuperGood

Quote
Also some objects already have a type (which is a uint8), so another get_type() returning a former besch * will add confusion ...
That method should be refactored into something more meaningful such as get_classification(). The return value is an abstract indicator as to the object type, a classification for the object, without needing to know the details of the object type. Sure it is slightly longer, but also more meaningful.

In theory besch type objects can be considered to represent an entry in a database of sorts. They also represent available types.  Hence it might have more meaning to label them so.
object_type_entry_t
factory_type_entry_t
way_object_type_entry_t
etc...
Unfortunately this does result in quite long type names. However there should be no ambiguity. The accessor method would then be get_type_entry().

prissi

#276
The besch are structured data. I fail to see them as entry in database. Also, the names should be probably shorter since they are used a lot.

And desc could also mean descriptor (how to arrange the data), if you are really into database stuff.

EDIT: removed typo and explicit references for clarity

Dwachs

I made some progress replacing 'bild' by image in the code. Here, I did translate the bild-besch classes as:

bild_besch_t -> image_t
bildliste_besch_t -> image_list_t
bildliste2d_besch_t -> image_array_t

As these data structures contain just images, I found 'image_t' more appropriate (without any desc/type suffix). What do you think?
Parsley, sage, rosemary, and maggikraut.

Ters

I can certainly think of arguments against such naming, but I'm not sure if I would agree with them myself.

DrSuperGood

Quote
The are mostly structured data.
What does this even mean?

Quote
What do you think?
A possible confusion is with various image APIs such as in Java. They include more context such as colour model of the image to allow better general purpose interoperability.