Textfile queries

[Simons Mith]

I'm working through the game's text strings database, copy-editing tooltips, fixing ugly phrasing and so forth.

Occasionally a tooltips or menu option is a bit too cryptic, or simply doesn't provide any actual information, and I seek clarification.

First up is this one, and there might be one or two more to follow:

Before:

Menu option: 'Enable multiple NewGRF engine sets: {STRING2}'
Help text: 'Compatibility option for old NewGRFs. Do not disable this, unless you know exactly what you are doing!'
Error message: '{WHITE}Changing this setting is not possible when there are vehicles'

After:

Menu option: 'Enable multiple NewGRF engine sets: {STRING2}'
Help text: 'This is a compatibility setting. It was used to avoid conflicts between very old NewGRF engine sets. Its default is 'On', and it should not need to be changed in normal use'
Error message: '{WHITE}This setting cannot be changed while any company owns vehicles of any type'

I've changed it mainly because 'Do not disable this, unless you know exactly what you are doing!' is highly uninformative and even a bit patronising. Don't tell people 'Don't change it,' tell them what it's for, thus assuring them they'll never need to change it.

But 1) is the changed version factually accurate? 2) Is this setting even needed any more or could it be removed entirely?

[Transportman]

I was always wondering why this setting is still in the Advanced Settings. Is there any reason at all to turn it off? And is that reason enough to keep it so easily accessible?

[planetmaker]

I was always wondering why this setting is still in the Advanced Settings. Is there any reason at all to turn it off? And is that reason enough to keep it so easily accessible?

I was wondering the same

I'm working through the game's text strings database, copy-editing tooltips, fixing ugly phrasing and so forth.

Much appreciated!

Menu option: 'Enable multiple NewGRF engine sets: {STRING2}'
Help text: 'This is a compatibility setting. It was used to avoid conflicts between very old NewGRF engine sets. Its default is 'On', and it should not need to be changed in normal use'
Error message: '{WHITE}This setting cannot be changed while any company owns vehicles of any type'
(...)
But 1) is the changed version factually accurate? 2) Is this setting even needed any more or could it be removed entirely?

Technically it's the question whether the NewGRFs share the same ID space or whether vehicle IDs are local to the NewGRFs without interfering with others (unless it explicitly states it wants to, gives the NewGRF-ID and the vehicleID it wants to interfer with. With this setting set to 'OFF'). NewGRFs unconditionally overwrite vehicleIDs of NewGRFs which preceed it in the NewGRF settings.
Some very old NewGRFs rely on being able to overwrite / amend the vehicles of NewGRFs loaded before them. But the amount of NewGRFs still in use and tailored for this can probably counted with the fingers on one hand.

The setting cannot be removed entirely without consequence for being able to load decently some (very) old games; but meanwhile it can be banned to openttd.cfg only IMHO.

[Eddi]

But the amount of NewGRFs still in use and tailored for this can probably counted with the fingers on one hand.

OpenTTD has some hardcoded overrides for the handful of known sets that rely on this, but there could still be unknown or forgotten ones... (last time i looked the number was 3)

The setting cannot be removed entirely without consequence for being able to load decently some (very) old games; but meanwhile it can be banned to openttd.cfg only IMHO.

that's probably true.

[frosch]

But the amount of NewGRFs still in use and tailored for this can probably counted with the fingers on one hand.

OpenTTD has some hardcoded overrides for the handful of known sets that rely on this, but there could still be unknown or forgotten ones... (last time i looked the number was 3)

You are only considering the valid usecases. 99.99% of cases will be people having added 60 train sets because they sound cool, even though only the last one "wins".

[Simons Mith]

Heh, I'm guilty of what frosch says. But you don't always get much feedback about which NewGRFs play nicely with which other ones, so I tend to just take the chance. [Although making it easier to view the text readme files for NewGRFs in-game has been a big help] My view is if it works, great, if not never mind. I do always sort NewGRF into alphabetical order (barring clashes or load order requirements) so that I get consistent behaviour from what I have loaded.


Anyway, next query:

Before:
Option: Keep building tools active after use: {STRING2}
Helptext: Keep the building tools for bridges, tunnels, etc. open after use

After:
Option: Keep tools for self-contained buildings active after use: {STRING2}
Helptext: 'Self-contained' means structures like depots, road stations and airports, where placing a single object with one click gives a complete facility

I was going to say 'single tile', but airfields are an exception to that. But these entities behave differently from the railway station builder UI, where you may build a station a few tiles at a time rather than all in one.

Is this better? Is the rule correct and complete? Can anyone suggest a better way to phrase it, or think of any exceptions? For bridges and tunnels, the UI always disappears because you have to click twice, for the start and endpoint on the map for each bridge/tunnel, so they're definitely incorrect examples to cite anyway.

BTW, the waypoint UI probably ought to fall under this rule, and at present it doesn't.

[kutagh]

Well, unless I have been doing something wrong, tunnels need only one click (at the startpoint, the appropriate endpoint is automatically found) and you can't select specific types (I assume you're talking about the window that asks which type of bridge you want to build, which is dependent on bridge length too).

[Simons Mith]

Three more:



On the toolbar:

'{BLACK}Fast forward the game'

How fast? Does it run as fast as the computer can go, or does it have a speed cap? I have a slow computer by today's standards and I can't tell.


'{BLACK}Show last message/news report, show message options'

Wait, I don't remember this menu ever giving direct access to message /options/. Did it used to? Even if not, it would be very useful if it did, and I'd like to see it added/restored. But ATM it does 'Last message/News report' and 'Message history' only.



In the advanced config menu:

'Road vehicle queueing (with quantum effects)'

'with quantum effects' looks to me like a bit of cryptic dev shorthand that made it into the main game. It ought to have been squashed by now. Does it mean 'Vehicles may visually overlap?' I believe it's a fudge to handle the road vehicle AI's currently poor queueing skills, but I think I'll need some suggestions/inspiration to fix this one.

[Simons Mith]

Another one: 'Number of stations served recently. Train stations, bus stops, airports and so on are counted separately even if they are part of the same station'

What precisely counts as sufficiently different? I would presume that it's the four 'station vehicle' icons that are the key. So an airport counts as one whether it's served by helicopters, aeroplanes or both. A vehicle station with passenger trams and cargo lorries counts as one. A dock joined to an airport and a train station cannot count as more than three, no matter what mix of ships, trains and aircraft use it. Is this right?
Tx.

[Eddi]

i have never ever seen this string before...

[Simons Mith]

Sorry, that's an 'after' string.

'Number of recently-served stations' - is the start of a help tooltip in the stations row of the 'detailed performance rating' window. Part of how your game score is calculated.

[Simons Mith]

I'm getting close to finished now, and will be asking for a guinea pig or two - probably a dev-guinea pig, before too long. Any answers/suggestions re the outstanding questions - especially the 'quantum effects' one which has me most puzzled - gratefully received.

Another one: You can set an autorenew cash limit. But unlike one's max loan it doesn't appear to be inflation-linked. Shouldn't it be?
Also, it grows £40k at a time, which is kind of an odd growth rate. I'd suggest making it a percentage of one's base loan.

I wanted to provisionally change the tooltip to say it's inflation-linked, but AFAICS it isn't, yet.

[Pingaware]

'{BLACK}Fast forward the game'

How fast? Does it run as fast as the computer can go, or does it have a speed cap? I have a slow computer by today's standards and I can't tell.

Simply runs it as fast as the computer can run it at that moment in time as far as I know. As a result, the actual speed increase can change while it's running (I think).

[Alberth]

'{BLACK}Fast forward the game'

How fast? Does it run as fast as the computer can go, or does it have a speed cap? I have a slow computer by today's standards and I can't tell.

Simply runs it as fast as the computer can run it at that moment in time as far as I know. As a result, the actual speed increase can change while it's running (I think).

Your knowledge and thoughts are all correct.

It also means the button has no effect when you are already hitting the CPU limit.


By the way, the button also works for networks of two stations and one train, I am pretty sure you'll see the difference

[Simons Mith]

OK, thanks all. Still plugging away - and the next question is whether I have to compile the entire game in order to try out the new strings for myself. I really just wanted to generate a new .lng file and drop it in, if that's possible...?

[Eddi]

In Theory (tm) you can just use strgen to create the language file, but the precompiled one is horribly outdated, so you have to compile your own anyway.

[Simons Mith]

Right, who's feeling guinea-piggy? Hint, don't try this unless you are hep to the concept of backups.

OK, one drastically rewritten string database coming up. I'd call this about version 0.75. The .lng file is also attached. This is based on build 26305 which isn't 100% current (I think it's pre-beta-4), but not too out of date.

The english.txt file is not quite complete but close, and I think it's time to get some eyeballs on it other than mine.

For one reason or another I have touched just about every string in the game. I will be producing a mini-style guide summarising the kinds of changes I have made, and documenting future guidelines to help keep things consistent. Could help the translators too.

Some of these changes are, I'm sure, a step too far, but I wanted to try them anyway.

Here's a thematic summary of what I've been mucking about with:

0. INTERNAL COMMENTS: Some tweaks to comments and some additional asides on things I noted in passing. Flags for places where the game code needs to be altered to match wording changes in config menus.
Impact: NONE

1. TYPOGRAPHY CHANGES: english.txt fully supports UTF-8 now, and has done for ages, so I've taken the chance to use correct sexed quotation marks throughout, multiplication signs instead of lower-case x's, en dashes instead of hyphen minuses, ellipsis instead of . . . and I've put in a handful of other special symbols. For example, the / symbol almost always indicates either/or. In about 5 places it's used for division, so in one of those cases as a test I've tried the proper division symbol. We could also use characters like em spaces in this text file and it would work fine, although they would be hard to see.
Impact: MINOR

2. NBSP's EVERYWHERE: This one's dubious. The trouble is that OTTD dynamically sizes its buttons and pulldowns to exactly fit the text in them, but this makes the entire game UI feel needlessly cramped IMO. So I tried adding a hard space - NBSP - to the start and end of every string. I think it helps a lot, but it means there are a few cases where text alignment looks funny. For example, multi-line tool tips and particularly pull-down menus which have extra material from NewGRFs, where the extra NewGRF strings don't benefit. There are also cases where the NBSPs aren't needed because the button/window title/whatever is already plenty wide enough, but in these cases it does no harm, so I've left it in. A better way to do it would be to make coding changes to set a larger window border for tooltips, pull-downs and so forth. Just a few pixels would be enough. This way is just a kludge. I would also like opinions on whether this looks horrible for those who use a variety of different font typefaces and sizes. Places where I like it - I think the train, bus, ship and aircraft icons look a lot better with a bit more personal space. Many default left-aligned buttons also benefit. OTOH the order interface I KNOW is buggy, because there's some double-spaces in there I haven't cleared out properly yet. This change is easy to revert; a search for {NBSP} and replace with nothing strips them out pretty cleanly.
Impact: SIGNIFICANT. COSMETIC EFFECTS ON NEWGRF UIS

3. COLONS PURGED: In addition to manually adding the extra spacing, I've stripped out practically all the game's colons. Also dubious, but they made everything look very fussy IMO. Some could be put back, but on the whole the fact that we colour game values differently from the surrounding text makes them distinct enough. Still, I'd be grateful for feedback.
Impact: SIGNIFICANT. COSMETIC EFFECTS ON NEWGRF UIS

4. UI CONSISTENCY: I tried to make the capitalisation in buttons and window titles consistent. This is impossible to get perfect at the moment because the existing strings aren't used entirely consistently. Sometimes button text is reused for a window title, sometimes a new text field is used. I also note mispellings and bad english in the embedded game parameters, such as STR_JOIN_STATION_CREATE_SPLITTED_STATION (sic). Consistently calling window titles titles and buttons buttons would be a help, but that's a separate job I don't really want to touch at all, because tidying that up would touch almost the entire codebase. The rule I've tried to follow is that window titles always use title case, buttons use initial caps only. Embedded dynamic text uses initial caps, no colons, and coloured text.
For example, take a string like {SILVER}{NBSP}Cost {GOLD}{0:CURRENCY_LONG} {SILVER}Running cost {WHITE}{4:CURRENCY_LONG}/yr{}{SILVER}Capacity {WHITE}{5:CARGO_LONG} {SILVER}Weight {WHITE}{1:WEIGHT_SHORT}{}{SILVER}Speed {WHITE}{2:VELOCITY} {SILVER}Power {WHITE}{3:POWER}{NBSP}

The result is something like:

Cost £55,215 Running cost £12,500/yr
Capacity 100t Weight 40t
Speed 55mph Power 5000lbf

The numeric values are in white, except for the cost which is in gold, and the text labels are in silver.
Progress: 95% (max for now)
Impact: Minor

5. MORE USE OF COLOURS: I have used colours in a couple of additional places, but stripped them out in others. Again, I'm experimenting. Most notably, when auto-replacing vehicle models when old, 'when old' is coloured. On the vehicle orders UI, 'Jump to' orders are in blue. This makes it easier to filter them out when you're checking other parts of a vehicle's orders. One could make depot, refit and stop orders coloured too, but a riot of colour would make things worse again. Red for stop might be OK as well though, but I doubt going much beyond that would be wise. I do plan to look at defining a consistent set of rules to follow in the style guide, and that will include colouring and window layout. Comments on colour choices and consistency welcome.
Impact: COSMETIC

6. HELIDEPOTS ARE NO MORE: Helidepot is a hideous coinage. Instead of Heliport/Helidepot/Helistation, I've put in Helipad/Heliport/Helistation. Helipad's much better!
Impact: MINOR

7. SMALL AND INTERCONTINENTAL AIRPORTS ARE NO MORE: 'Intercontinental' is a fantasy term not used in real life. Instead of Small/City/Metropolitan/International/Commuter/Intercontinental, I've put Airfield/City/Metropolitan/National/Commuter/International. Much better IMO.
Impact: MINOR

8. DEPOTVERHAUL: SWIDT? Vehicle depot names are also clunky. Especially Road Vehicle Depot. But if we used /Rail/ Depot instead of Train Depot, then we could also adopt /Road/ Depot instead of Road Vehicle Depot while still remaining consistent. I've also tried renaming Ship Depots, another game-specific term, to /Dock/ (if /drydocks/ could be added, that would be fantastic), and the existing Docks could become Wharfs or Quays. I've gone for Wharfs, but would welcome opinions. Thus we end up with Road Depot/Rail Depot/Tram Depot/Dock/Hangar
Impact: MINOR

9. NO. NO. NO. YES: The fallback numbering system when the game runs out of station names works but it has always felt rather modern to me. The old-fashioned way to do it would be to use 'No.' (or even No. using a superscript) instead of '#', so I've made that change. I felt I could get away with it having made Road Vehicle Depot names so much shorter.
Impact: MINOR

10. 'HEADS' ROLL: I've moaned about ita couple of times, then found where the setting was really controlled from. We now have the traditional english term of /head/ of livestock. I've also experimented with /sacks/ for mail, /gold bars/ instead of bags of gold, (or we could have bags of bullion if people like that) and /strongboxes/ instead of bags of valuables. It doesn't seem to have broken anything. Are these changes safe?
Impact: MINOR

11. ROAD VEHICLE: Another experimental change. We have 'trains', 'ships', 'aircraft' and 'road vehicles'. And trams, trucks, lorries, buses, cars, taxis, coaches... within the latter category. But in context, you generally know when 'vehicle' refers to all classes of vehicle, and more often than not when you see the word 'vehicle' it can only be referring to a road vehicle. So we're insisting on always calling them 'road vehicles' to avoid an ambiguity that hardly ever shows up in the game anyway. Why not just call them 'vehicles', except in the very few UI cases where the distinction does matter? I've tried implementing this, to see if it causes any problems or confusion. A better fix might be to define some vehicle subtypes for road vehicles so we can be more specific, but that would mainly be a cosmetic refinement.
Impact: MODERATE

12. GREATER VISIBILITY: You can't talk about 'toggling' transparency settings when there's more than two options - in this case, visible, transparent and invisible. So I've renamed the window and its assocated settings to Visibility.
Impact: COSMETIC

13. TOGGLES: 'Toggle' is a quite a specialised technical term, and it's misused in many places in the game. I haven't cleared all the instances out yet, but in general talking about turning a setting on or off is clearer, particularly to non-technical users.
Progress: About 80%
Impact: MINOR

14. TOOLTIPS: The bit I started out with. Mostly done, and feedback and comments welcome. In many cases where the old tooltip was obvious, I've tried to add some extra useful information rather than just explaining something that needs no explanation.

15. REVERSED CONFIG SETTINGS: In some cases, usually where there was a double negative, I have reversed the sense of the config string. Rather than 'Disable airport expiry: Yes/No' I've changed it to 'Airports expire: Yes/No,' which makes it much clearer what's going to happen, /but requires code changes outside english.txt to fully enact./ I haven't done those coding bits, because I wanted to limit myself to just breaking one file. For now at least.
Impact: MINOR

16. STRING PARAMETERS: Sometimes, I've reordered text strings into a more logical sequence, grouping related ones together and listing them in descending order of importance. Cost+Running cost are logically associated, both being costs. Similarly Speed, Power and Tractive effort, and of those three Speed is probably the most important. One might quibble, but a single vertically-scannable column that shows Cost, Speed and Cargo capacity is obviously more helpful than having them mixed in amongst the other vehicle parameters. Where the string order changes, this breaks the other language translations, so I'm trying to manually add the parameter numbers in everywhere so that future string reordering doesn't break things. Not complete.
Progress: About 40-60%
Impact: MINOR

17. REMOVED MAX: The game pedantically lists 'Max Speed' and 'Max Tractive Effort' for vehicles, whereas in practice it's obvious that's what they are and the 'Max' is redundant clutter. Hence I've removed the word, throughout almost the entire game.
Impact: MINOR

18. COLUMN LAYOUT: I couldn't help but notice that english.txt, even though it can be quite hard to read, is at least laid out in a two column format. The game UI itself usually isn't. In particular this makes the town, industry and station directories needlessly hard to follow. Making these parts of the game conform to a column layout is outside my skills, but it surely overdue. Anyone willing to give it a go? While there's all these other text changes to integrate anyway?
Impact: MODERATE

19. STATION NAMES: In an older post of mine I did a census of names on the London Underground. Would be nice to plumb them in and banish bus stations called 'Sidings,' for example, from the game. This is the one class of change I've been mucking about with that isn't in. I hope to do a separate article on station naming, town naming, and even integrating it with the town world generator. Lots of niggles here - such as the strange in-game prohibition on towns having more than one church, where in practice a lot of even quite small english villages have two or three. Big job; not for now.
Progress: 1-5%
Impact: LARGE

20. FINALLY: Please let me know which changes are acceptable in the short term, and I can provide a text file with just a subset of the changes. I don't really expect all of the things I've been mucking about with to be accepted, but the easiest way to get a consensus is to let people try them and see what they think.

[Eddi]

1. TYPOGRAPHY CHANGES
Impact: MINOR

this one is kinda problematic, as additionally to the UTF-8 support, the english (and most european) languages are somewhat restricted to the builtin sprite font. if the language uses characters not in this sprite font, a random system font is taken. (and we have no proper font setup dialog). so unless you extend openttd.grf with these extra characters, you effectively made the sprite font useless.

2. NBSP's EVERYWHERE:
Impact: SIGNIFICANT. COSMETIC EFFECTS ON NEWGRF UIS

you should probably adjust the GUI code instead.

[frosch]

I've processed the file into a diff.

About 2:
Eddi said about everything. Padding should not be done via strings. Padding is not something that needs translating.
I've reverted all these changes in the diff.

About 1:
This is fine, if someone draws the sprites, which are not too many. For now I've reverted these changes, since they obfuscate the real changes.

About 3:
It looks like you removed the colons with search and replace. Some places look really broken without the ":", some places render the string uncomprensible:

-STR_AI_LIST_AUTHOR :{LTBLUE}Author: {ORANGE}{RAW_STRING}
-STR_AI_LIST_VERSION :{LTBLUE}Version: {ORANGE}{NUM}
-STR_AI_LIST_URL :{LTBLUE}URL: {ORANGE}{RAW_STRING}
+STR_AI_LIST_AUTHOR :{LTBLUE}Author {ORANGE}{RAW_STRING}
+STR_AI_LIST_VERSION :{LTBLUE}Version {ORANGE}{NUM}
+STR_AI_LIST_URL :{LTBLUE}URL {ORANGE}{RAW_STRING}
-STR_DIFFICULTY_LEVEL_SETTING_MAXIMUM_NO_COMPETITORS :{LTBLUE}Maximum no. competitors: {ORANGE}{COMMA}
+STR_DIFFICULTY_LEVEL_SETTING_MAXIMUM_NO_COMPETITORS :{LTBLUE}Maximum competitors {ORANGE}{COMMA}

-STR_CONFIG_ERROR_DUPLICATE_GRFID :{WHITE}... ignoring NewGRF '{RAW_STRING}': duplicate GRF ID with '{RAW_STRING}'
+STR_CONFIG_ERROR_DUPLICATE_GRFID :{WHITE}... ignoring NewGRF '{RAW_STRING}' duplicate GRF ID with '{RAW_STRING}'

Scanning through the diff I consider about 70% of the ":" removal wrong, and 30% questionable

The diff is attached (with and without context) for easier scanning than reading the whole file.

[Simons Mith]

Colons: Yes, I started manually, but in the end went to S+R. There were just so many! But this change isn't going in anyway, so, no problem.

Hard spaces: Yeah, I quite agree with you both. If it's to be done it should be done properly. But (apart from in multiline tooltips where it breaks again) the game does look better with that little extra bit of spacing in, doesn't it?

Bitmap font: How do you trigger the bitmap font then? Where's it used when it is used? I've never encountered missing symbols or font style discrepancies or I'd have noticed the missing symbols. Everything has /looked/ fine to me. Current pedantic list of extra characters needed: en dash, ellipsis, multiply symbol, division symbol, subtraction symbol, left curly quote, right curly quote, left double curly quote, right double curly quote.