Streetcomplete: Spelling and word choice issues (mix of British and American strings in strings.xml)

[huftis]

This is just a spin-off of the discussion in #883. Currently, the strings.xml file has a mix of British and American strings, with a few spelling mistakes and typographic issues. Here we can discuss how to handle this.

I think US English is usually used as the default for English-based Android apps, with UK English provided as a translation. But it looks this isn’t a requirement, and in #883 there was a preference (?) for having UK English as the default. So here’s my proposal:

My proposal:

• The US English strings.xml will be changed to UK English. At the same time, any spelling mistakes found will be fixed (e.g. ‘housenumber’ will be changed to ‘house number’) and typographic fixes will be applied (e.g. hyphens used as dashes will be changed to typographically correct en-dashes (- to –) and ASCII apostrophes will be changed to typographically correct apostrophes (' to ’). I can create a PR for this.
• A US English translation is added to POEditor. This will for example change ‘cancelled’ into ‘canceled’ and ‘car park’ into ‘parking lot’. I can create the initial translation, but it would be nice if someone could proof-read it.

Even for UK English, there are spelling and grammar choices to be made. Based on the style used in the official Android translation (and in other free software projects), I propose to use -ise instead of -ize and to omit the listing comma in front of ‘and’/‘or’ (e.g. ‘red, green and blue’, not ‘red, green, and blue’). (There might be other relevant style choices I have missed, but I will mention them in this issue if I discover any when reviewing the strings.)

Comments?

[westnordost]

Germans are the probably the worst in writing & speaking the english language

Somewhat of a generalization. I consider my English skills (in writing) rather good. So far, I have seen very few complaints / suggestions for improvements on the default translations.

Anyway.

An US English translation should still not be added to POEditor because in POEditor, there is no concept of inheriting strings from the "base" language (en-US inherits from en). I want to avoid maintaining two translations that are almost identical.
Instead, let's have the strings.xml in US English (as "the Internet" and Android speaks US English) and add a GB English strings.xml which contains _only_ those strings that differ from the default.

(P.S: I still do not have a strong preference whether the default should be US English or GB English)

[huftis]

I’m not sure I understand your last comment, @westnordost. By having strings.xml in US English, we are setting the ‘default’ to US English. But I don’t have a problem with the US English being the default. (Actually, having it as the default might have a few advantages.)

But I don’t agree with having a UK English translation that only includes the strings that differ between en-US and en-GB. If a string is missing from the en-GB (or en-rGB, as the Android identifier will be) file, we won’t know if it’s because the string should be identical to the en-US string or because the string was never reviewed (i.e. checked by a translator). By having a complete en-GB translation, we would always know if a string has been reviewed. It’s not much work creating the initial translation by copying all the en-US strings that don’t differ in US English and UK English over to the en-GB translation.

[westnordost]

My fear is that over the time, the two translations will veer away from another. Not because the translations should really be different, but out of personal preferences of one or the other translator.

[huftis]

I don’t think that will be a problem. Having complete translations for en-GB is what other free software projects do (for example, KDE does this, with a couple of hundred thousand strings …). And one can (and should) of course communicate with the en-GB translator(s) that any string ‘improvements’ should be made in the source (en-US) strings.

It’s also easy to show which strings differ between the en-US and en-GB translations (in fact, running a simple ‘diff’ might work). So one can run period ‘reviews’ of the differences between the two translations.

[westnordost]

Okay.

[huftis]

I also found this rather nice guide to writing in the ‘Material Design’:
https://material.io/guidelines/style/writing.html

I’ll try to take it into account when updating the strings. For example, the guide mandates ‘sentence case’ for titles, headings, labels and menu items, so I’ll change ‘Map Cache Size’ to ‘Map cache size’.

(Perhaps we could also think about a using a more easily understand word than ‘cache’, cf. the ‘Write for all levels of readers’ section in the guidelines, but I’ll leave such word changes / improvements for a potential future issue, and only change inconsistent/misspelled words and incorrect grammar in this PR.)

[rugk]

I think you cannot find a better word than cache. Also browsers use it.
You may, however, be able to avoid it by just stating that it deletes the _background map_ or so.

[westnordost]

This could still get into v5.0 even though v5.0-beta2 is already out. @huftis are you still working on it?

[huftis]

@westnordost There’s not much work left, but I would prefer to wait till v5.1 (or v6.0 or whatever the version after v5.0 will be called). I’m not a fan of last-minute (non-bugfix) changes in an app that’s already in the beta process. Too risky. :)

[SuborbitalPigeon]

It's also useful to use a British English "translation" as a proof read. I'd be very happy to help, I'm a GNOME en_GB translator.

[huftis]

That great, @SuborbitalPigeon! I plan to have a PR ready sometime next week. I’ll ping you when it’s ready, so that you can take a look at it.

[huftis]

@SuborbitalPigeon Here’s a simple diff view of my proposed British English ‘translation’: https://rawgit.com/huftis/9586a387561ce849c0bfd3209c88db1f/raw/4d6c7d7b53c63fef6ebf9c181dfd4a351c90557f/diff-us-to-gb.html

Note that the source files used for the diff includes quite a few changes (not yet committed) in the original strings (among them several en-GB → en-US changes), but the diff only shows the actual en-US → en-GB changes.

I have tried to use the en-GB spelling used in other free software projects (and in the en-GB Android localisation), e.g. -ise instead of -ize and single instead of double quotation marks. I initially wanted to translate ‘Soccer’ into ‘Football’, but as the en-GB translation may be used by people from all over the world (except the US 😃), I think it’s more important to have unambiguous descriptions. So I ended up with the compromise ‘Football (soccer)’. (For a similar reason, I didn’t change ‘American football’ into just ‘Football’ for the en-US source string.)

I would be grateful if you could take a look and see if my proposed translation is acceptable. If you could also take a quick proofread of the original strings (i.e. the non-coloured strings) and see if you spot any obvious mistakes / possible improvements, that would be great! Just write any issues you find here, and I’ll include them in my (coming) pull request.

[SuborbitalPigeon]

A few comments.

• about_summary_license: "GNU General Public License": may as well make the change here as well. I appreciate the legal name is with the 's' though.
• quest_sport_soccer: [-"Soccer"-] {+"Football (soccer)"+}: I'd just leave this as 'Soccer', because it's clear enough as is.
• quest_wheelchairAccess_subway_entrance_title: Is this [-subway-] {+tube+} entrance wheelchair accessible?: 'tube' is a London term, I think 'Underground' would be reasonable here. Fun fact: the one in Glasgow is called the Subway!
• quest_parkingType_multiStorage: [-Parking garage-] {+Multistorey+}: 'Multistorey car park' perhaps, more obvious what it is.

I didn't know about the double vs. single quotes thing. You learn something new every day!

[rugk]

As for GPL – you should not change that. It is the proper name of the license, so don't adjust that.

[huftis]

@SuborbitalPigeon Thanks! My comments:

about_summary_license: "GNU General Public License": may as well make the change here as well. I appreciate the legal name is with the 's' though.

Yes, the name of the license uses the US spelling, so we have to use this spelling too (this is true for other translations too, possibly with the exception of languages that transcribe English words to a different alphabet).

quest_sport_soccer: [-"Soccer"-] {+"Football (soccer)"+}: I'd just leave this as 'Soccer', because it's clear enough as is.

OK. My thinking was that it was more natural for someone from the UK to look for ‘football’ in the list of sports. But I’ll revert the change. :)

quest_wheelchairAccess_subway_entrance_title: Is this [-subway-] {+tube+} entrance wheelchair accessible?: 'tube' is not used outside of London, the Glasgow Subway for example. Perhaps 'Underground' instead?

OK, I’ll change it to ‘underground’.

quest_parkingType_multiStorage: [-Parking garage-] {+Multistorey+}: 'Multistorey car park' perhaps, more obvious what it is.

It’s displayed as one of three responses to the question ‘What kind of parking is this?’, and space is at a premium for these kind of strings. So I don’t think adding ‘car park’ is necessary. But since one of the other strings is ‘car park’, having ‘car park’ here too might be a good idea?

Let’s use ‘Multistorey cark park’ for now. We can always revert if we find that it takes up too much space in the UI.

[SuborbitalPigeon]

@axre oh dear, that means a lot of stuff will need to change in GNOME then.

It’s displayed as one of three responses to the question ‘What kind of parking is this?’, and space is at a premium for these kind of strings. So I don’t think adding ‘car park’ is necessary. But since one of the other strings is ‘car park’, having ‘car park’ here too might be a good idea?

I didn't look at where the strings are actually displayed, so the shorter version seems a good idea.

[huftis]

@SuborbitalPigeon:

I didn't look at where the strings are actually displayed, so the shorter version seems a good idea.

OK, I’ll use the shorter version.

[huftis]

I’ve now added a PR for all the changes (#1078). For your convenience, here’s a coloured word diff of all the changes in the source strings: https://rawgit.com/huftis/6899ade3dee1df0eb09b2e6783446f4b/raw/cdb49eccb638b48941442babb3250aa34bdcfce5/string-diffs.html

Regarding the word choice changes, they are mainly to make the text into proper US English. If there was a choice between a ‘more British’ or ‘more American’ word, I chose the American word. That’s the advantage of having both an American and a British ‘translation’. 😃 So if you dislike a word choice, you will probably prefer the British English translation (that is also added in the PR); see https://github.com/westnordost/StreetComplete/issues/914#issuecomment-390471374 for a link the en-US → en-GB word diff.

[rugk]

@SuborbitalPigeon

GNOME? We are here at StreetComplete. I guess, you mixed up the issues here…

[SuborbitalPigeon]

No, it was just an offhand comment.

[rugk]

Then I don't see what this has to do with GNOME…

[SuborbitalPigeon]

That's my point, it doesn't. I was just observing that I've been changing the licence text in the GNOME applications I've translated.