Topic: named building rotations (citybuildings, curiosities, factories)

[Leartin]

I noticed that buildings with 8 rotations would show blank for the later 4 rotations, rather than numbers. Wanted to fix that, figured I could actually name them. (see screenshot).
Might not be 100% accurate in the sense that a building without rotation is still called "south-facing" and factories/curiosities don't actually care which side the road is, but if someone is really offended by that they can always translate the descriptions back to numbers 0 to 7.



Because it's so neatly together, here is just the code snippet instead of a patchfile:

Code: ( extend_edit.cc (before)) [Select]

static const char* numbers[] = { "0", "1", "2", "3" };

gui_rotation_item_t::gui_rotation_item_t(uint8 r) : gui_scrolled_list_t::const_text_scrollitem_t(NULL, SYSCOL_TEXT)
{
rotation = r;

if (rotation <= 3) {
text = numbers[rotation];
}
else if (rotation == automatic) {
text = translator::translate("auto");
}
else if (rotation == random) {
text = translator::translate("random");
}
else {
text = "";
}
}


Code: ( extend_edit.cc (after)) [Select]

gui_rotation_item_t::gui_rotation_item_t(uint8 r) : gui_scrolled_list_t::const_text_scrollitem_t(NULL, SYSCOL_TEXT)
{
rotation = r;
switch(rotation) {
case 0:         text = translator::translate("south-facing");       break;
case 1:         text = translator::translate("east-facing");        break;
case 2:         text = translator::translate("north-facing");       break;
case 3:         text = translator::translate("west-facing");        break;
case 4:         text = translator::translate("southeast corner");   break;
case 5:         text = translator::translate("northeast corner");   break;
case 6:         text = translator::translate("northwest corner");   break;
case 7:         text = translator::translate("southwest corner");   break;
case automatic: text = translator::translate("auto");               break;
case random:    text = translator::translate("random");             break;
default:        text = "";
}
}


[prissi]

I thought the numbers were more friendly for addon creators, who are the main users of this tool. But why not.

I would still prefer a patch file though ...

[Andarix]

I thought the numbers were more friendly for addon creators, who are the main users of this tool. But why not.

I would still prefer a patch file though ...

I think tab translated is ok. Tab object then numbers.

[Leartin]

I can see your point with the numbers, but everything in that dialog (save for the the "object" tab) is catering to regular players who want to place things on the map. If it's supposed to help addon creators, it could display "type=res" rather than translatable "residential houses" etc., but it doesn't.
I'd think it more helpful for creators if they can easily check whether the graphics correspond to the correct rotations after they made them - that the "north-facing" rotation actually is facing north etc - with just the numbers, they'd have to build it with the auto-rotation along roads and/or rotate the whole map to see how the placed building rotates.

Maybe someone is willing to give further opinions on that - can't provide a patch right now anyway, since I'm playing around with that file trying to get a climate filter in.

[Vladki]

Perhaps - as there is a tab with translations and tab without - rotations should be numbered if building names are not translated either and vice versa.

[Leartin]

Perhaps - as there is a tab with translations and tab without - rotations should be numbered if building names are not translated either and vice versa.

The tabs only update the list, nothing else of the gui is affected, so that's not as easy as it sounds.
A simple solution could be to use a string like "(0) south-facing", hence showing both number and description. Win-win.

[makie]

A simple solution could be to use a string like "(0) south-facing", hence showing both number and description. Win-win.

This can be done in the translation and can be easy changed there.

The names in the program should be seen as key in the translation. It is not important how it is named exactly in the program.
A number only, like "0", cannot be translated, so these strings are good for solving the problem.

[Leartin]

For example, the translation key for both the label-placing-tool and the label dialog is "Marker", which is translated in English as "Place a sign". That translation fits for the tool, but not the dialog (since the dialog shows an already placed signs content). There are two ways to look at this - either the fault lies with whoever translated this way for interpreting it too much and deviating from the original meaning (1), or the fault lies with whoever reused the key in the program. (2)
In the case (1), it would mean that we shouldn't translate a key "south-facing" with the text "(0) south-facing", since that's not a perfectly faithful translation. Even if it fits now, that might change in the future.
In the case (2), it would mean that we should try to make keys as explicit as possible. Which means "(0) south-facing" would be better than just "south-facing", and something like "rotation 0; south-facing" would be even better as there is no mistaking it.

I'm certain that a translatable key is better than a number. But since it's not committed yet and nothing else built on it, there is no harm in trying to make it a key that everyone can agree on even if it's not translated. Eg. if most people prefered to use numbers, I'd suggest a key like "--0--" since you'd get the number you wanted without translation, but could still translate it.

[Essentially - an overthought, strict version of "even if it gets translated, don't just use a bunch of random characters as your placeholder"]

[makie]

case2
The key in the translation table should be unique.

If the program use at two or more position the same string or word as key, maybe in English it is the same word, but maybe it can be different translation necessary, at the various position of the program for  a other language.

We have this problem with the word "Gewinn"
sometimes it means "Income:" (per month) (line_management_gui.cc line 270)
sometimes it means "Annual profit:" (simconvoi.cc line 2628)

Better this named different.

[prissi]

The problem is also that most languages will not show a translated key for a long time. Hence better have something which is meaningfull in English at least. So maybe "south-facing (0)" or "0 - south facing" is better than "--00--"

(The Gewinn issue comes from the reworking of the economy in real finacial term sometimes in 82.xx while keeping the translations and things evolved from this. This is probably a bug report worth.)