News:

Simutrans Tools
Know our tools that can help you to create add-ons, install and customize Simutrans.

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.

An_dz

I don't see why koord should be world_coord I think coord is enough as it's obvious it's the coordinates on the world.

Vladki

Wolke literally means cloud, but I've not seen any other clouds than smoke in the game. Just wondering if there is a feature that I don't know about...

Sent from my ONEPLUS A3003 using Tapatalk


Leartin

Quote from: Vladki on April 13, 2017, 06:17:14 AM
Wolke literally means cloud, but I've not seen any other clouds than smoke in the game. Just wondering if there is a feature that I don't know about...
Aren't there clouds in p96c? :P

Without checking, I'd assume it's because smoke/Rauch is uncountable, while cloud/Wolke is countable. It's just linguistics, but it makes a lot more sense for a steam locomotive to spawn "a cloud" ever so often, rather than "a smoke". Or "Eine Wolke" rather than "Einen Rauch".

prissi

There was smoke for synchronised (sync_step) and asynchronous (step) smoke in old games. Now they are all smoke.

userfriendly

Translate karte_t to map_t. Proposed patch attached and a GitHub PR for reference: https://github.com/user-friendly/simutrans/pull/1
The patch is quite big, but there are no compiler errors (clang version 4.0.1-6).
Just be good to each other.

Ters

karte_t is supposed to become world_t, not map_t.

Dwachs

karte_t is the universe: it not only contains the map, it manages all the objects in the gam, it runs the game loop, etc. So neither translation world_t or map_t is right imho.
Parsley, sage, rosemary, and maggikraut.

jamespetts

Is "world" really different from "universe" in this context?
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

There might be multiple worlds in one universe. There can only be one world in karte_t.

userfriendly

Ok guys, I'm gonna stay out of the discussion, because it doesn't really matter to me. Either will work, I just want to translate the source to English (not that I don't like German!).
I'm willing to work and this seems like it can be done relatively easy, so if you have a list of words that everybody came to a consensus on, I'll gladly work on translating these, providing one patch per word.
Just be good to each other.

Ters

The hardest problem in the field of computer science is what to call things.

jamespetts

Quote from: Ters on December 05, 2017, 05:54:26 PM
There might be multiple worlds in one universe. There can only be one world in karte_t.

But there are not multiple worlds in the Simutrans universe, hence asking whether the difference is significant in this context.

Edit: Also, universe_t would be a lot to have to type many times when writing 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.

Ters

Quote from: jamespetts on December 05, 2017, 06:40:06 PM
But there are not multiple worlds in the Simutrans universe

So savegame_frame_t sees the Simutrans multiverse, then?

jamespetts

Quote from: Ters on December 05, 2017, 07:30:43 PM
So savegame_frame_t sees the Simutrans multiverse, then?

Possibly. I wonder how many multiverses that there are?

(But this is not quite the same, as there is only ever one karte_t object in existence at the same time. Indeed, I believe that it is now static).
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 December 05, 2017, 07:34:58 PM
(But this is not quite the same, as there is only ever one karte_t object in existence at the same time. Indeed, I believe that it is now static).

It was turned from a global to a singleton, which is just putting fancy wrapping paper on it.

jamespetts

Quote from: Ters on December 05, 2017, 09:04:19 PM
It was turned from a global to a singleton, which is just putting fancy wrapping paper on it.

I like wrapping paper. Does it also have a bow?
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


Leartin

Just call it "verse_t" - you wouldn't have to fight over whether it's multi- or uni-; it's short enough, and it sounds poetic :)

prissi

Although my first though would be poetic. Also, since world is English, maybe rather focus on the real German words ...

Ters

The files containing karte_t are already called simworld by the way.

Dwachs

Then let us translate karte_t to world_t and move on.
Parsley, sage, rosemary, and maggikraut.

userfriendly

Translate karte_t to world_t. Proposed patch attached and a GitHub PR for reference: https://github.com/user-friendly/simutrans/pull/2
No compiler errors (clang version 4.0.1-6).
Just be good to each other.

ACarlotti

I've produced a series of patches to complete the translation of komp->comp and komponente->component (and fix a nearby typo). (This has been partly translated in Standard but completely translated in Extended.)

1. Fix comment typo
2. Translate komp->comp in documentation.
3. Translate gui_komponente.(c|hh)
4. Finish translating komp->comp

prissi

Since there are some patches pending, this will be done when those have been incorporated, at least the big patch.

ACarlotti

Would this now be an appropriate time for the komp->comp patches? (I have an updated version that reflects recent changes).

On a (semi-)related note, I've been comparing some of the translation changesets in Standard and Extended recently. The attached diff arose mostly from looking at the translation of 'spieler', and is made mostly of typo fixes and variable renames. These are drawn largely from changes in Extended, where the version in Extended seemed better. (Conversely, where the version in Standard is as good as Extended, I've copied the Standard version for Extended). Is there any reason not to incorporate these?

prissi

This seems only comments and some underscore removal in names, so it makes sense to do this.

Ranran

Basically, for many contributors, English will help them understand the code better.
In extended, sometimes the German in the code has already been converted to English, and we may see differences in the code.
I submit a patch to replace "vehikel" with "vehicle", taking the opportunity of a conflict that arose in a recent merge.

I couldn't attach the patch file directly due to its size, so I'm attaching the compressed zip file. (´・ω・`)

Ranran

In Extended, ist_weg_frei is already extinct, but I noticed that can_enter_tile and ist_weg_frei are coexisting in standard.
The patch will replace the remaining ist_weg_frei with can_enter_tile.

Dwachs

submitted something similar.
Parsley, sage, rosemary, and maggikraut.

Ranran

I submit a patch to change the names of functions that have already been translated into English in extended, mainly factory-related function names.

vorrat_an
count_output_stock

input_vorrat_an
count_input_stock

geburt
purchase_time

keine_flags
no_flags

rem_supplier
remove_supplier

add_lieferziel
add_consumer

rem_lieferziel
remove_consumer

The upper one is the original German, and the lower one is the function name that was changed in extended.

However, there are still many German variables left in simfab...

Ranran

In standard, show_info() and open_info_window() are mixed, but in extended, show_info() is unified, and there is a difference.
Is there a reason why standard uses these differently?
There seems to be a history of translating zeige_info to open_info_window.

Dwachs

show_info is a used in classes derived from obj_t, open_info_window everywhere else. Could be unified.
Parsley, sage, rosemary, and maggikraut.

prissi

In found "geburt" to "purchase_time" not logical, at least not for buildings and trees. I could think of "appearance_time", "time_of_origin", "start_time",  "existing_time" if there needs to be time in the word.

Ranran

Quote from: prissi on January 31, 2022, 12:40:07 PMIn found "geburt" to "purchase_time" not logical, at least not for buildings and trees. I could think of "appearance_time", "time_of_origin", "start_time",  "existing_time" if there needs to be time in the word.
I totally agree but in extended, it was currently translated as such.
It's hard for me to think of the best word to use since I'm not a native English speaker.
If there is a change to another word, it can be merged to extended.

wlindley

I suggest spawn_time ... and it should uniform as game month.   As is, buildings have "game tick" in that field; I tried to change this awhile back but merge was rejected as "requires new save format" -- I will be happy to resubmit my changes