Some translations in simconvoi in order to make it more consistent with simline:
gib_name -> get_name
setze_name -> set_name
gib_fahrplan -> get_fahrplan
setze_fahrplan -> set_fahrplan
However, then we should migrate to set_schedule, imho ... get_fahrplan is not much better. But good that you are working on it.
So, patches that translate code are wanted?
But the cl**** is called fahrplan_t, so get_fahrplan is a little bit better :) Should we translate this too?
If you do not break something, go ahead ... But I understand what you mean. Hmm.
Then call it set_schedule and get_schedule?
Not sure. Maybe we need a policy for that. I man, you get a schedule_ptr ...
Imho going through all files and simply replacing fahrplan_t (and thus also zugfahrplan_t) will achieve the renaming of schedule. Although I am somehow reluctant to change a working system.
What does other people think of this?
I used to learn some German (yes, phrased like this is how it is/was), so it wasn't much of a problem. Read once, remember forever. I even learned some new words like Karte… :)
What drives me nuts is the get/gib + set/setze schism. If I want to fiddle with some value of object, browsing getters and setters through auto-completion right where I am writing code now is fastest method that does not require going somewhere else, but if the function can begin with more prefixes, it does not work.
So, I will do everything to get this unified, if I am allowed to.
Otherwise, changing terminology might be something not so easy - all comments, variable names and so on must change, too. For example, sometimes there are declarations like entwicklung_t entw, which would make little sense if only the type was translated. This should rather be part of other work on related areas of code, since it obviously needs more expertise than m**** replace.
Ok, lets decide: Changing gib/setze is a worthful goal. Other than this should be done handcrafted and with much more thoughs. Then this should be ready, I think.
I'm no developer myself, but I think getting as much of the code into English as possible, would sure make it easier for all non German speakers to work with. So anything that you think can be safely changed, probably should be changed.
But that's up for you code gurus to decide!
I may be wrong, but I bet that, if translated, more developers will join. My opinion is that the order should be:
- Name/files of cl****es
- Methods and attributes
- Local vars
- Comments
But it's too much work for doing it at once. When recoding something, translated the cl**** changed would be better. That way, more usual code would be naturally translated. I will give a try to the schedule cl****: fahrplan_t -> schedule_t
Patch for all gib/setze...
http://www.simutrans-germany.com/files/upload/gibsetze-2185.rar
Was this just text replacement or did you check for correct function? I mmean no forgib_error() into forget_error()?
Auto replace with trailing underscore_ and compile to test. Then I searched through diff for [_a-zA-Z]gib_ to find different patterns and found only one function which makes sense translated, too. No hits with same search for setze.
A man is worth his word. I've tried to change:
- fahrplan_t -> schedule_t
- fahrplan_t::fahrplan_type -> schedule_t::schedule_type
- convoi_t::gib_fahrplan -> convoi_t::get_schedule
- convoi_t::setze_fahrplan -> convoi_t::set_schedule
- simline_t::get_fahrplan -> simline_t::get_schedule
- simline_t::set_fahrplan -> simline_t::set_schedule
There was more than 900 references to change of the first item alone! I was looking for refactoring tools for Linux, and only found Netbeans with C/C++ plugin and experimental refactoring plugin. It worked very well when renaming the cl****, but failed to rename all occurrences of the methods. The patch is for rev 2186. Tested against compilation.
If some reliable refactoring tool is found, it is a question of seconds to safely rename a cl****/method/variable.
EDIT: Netbeans 6.5 is more reliable at refactoring. It can import the source code easily. It has internal support for svn. The only thing is that in the project properties form, the encoding is to be selected as iso-8859-1
I will finish today 101 version. All those patches will go to next version ...
Ok, schedule and get_/set_ incorporated into next version. YOu best update patches with a textditor search and replace. Sorry, I want to do it now, before other patches came around and give time to stop all possible errors caused by this.
Prissi,
thank you for doing this sooner rather than later - saved me a great deal of work updating patches!
Here is a small one... Since gib_kind changed into get_kind, it acquired a false meaning, probably close to gib_sorte or gib_type. Proper 100% English name is get_child.
Affects mainly innards of besch_t descendant cl****es, and vehikelbauer.
Would it be possible to have an "official" glossary of terms: German <-> English. I would like to contribute to finish the schedule cl****, but what would be the preferred translations for get_zwischenziel or get_ziel, for instance? get_transfer and get_destination? It would also help alien developers when revising not-translated code. A wiki page?
sourceforge still has un unused wike we could highjack for tcoding purposes. Probably the right place anyway.
Excellent! There can be an area for proposals and a person fluent in German to validate translation and make them "official". Once "official", translation patches can be submitted by non-German speakers... If I can help, please tell me.