Can I ask if or how it’s possible to create a new language? I know I’ve mentioned this before, but I would like there to be an en-GB. If we use WordPress as an indicator, their en-GB translation is 100% complete https://translate.wordpress.org/locale/en-gb/. I’m happy to take responsibility for it if necessary.
There was an en-GB on GlotPress as I added and updated translations for it.
Last time this came up I said that we probably weren’t quite ready for this yet. Now that we have a bit more experience with Crowdin and a new i18n lead we should be closer to being ready. So I’ll leave it to @ElisabettaCarrara to decide and coordinate.
Personally I’m also curious what value this would add to ClassicPress from you guys’ perspective, since it’s not something I’d be likely to want.
I think en_GB should be the default language on installation.
Late to the party…
I second @ozfiddler. The en_GB should be added and serve as a default for installations and as a default original from which we can derive other locales.
I will express my twoppence on adding locales and all that in the qarterly report I am preparing.
IMHO it has to be done with care, it’s something we should use to drive people in both as users and as contributors now that we are present on two major installers.
But, you’re also unlikely to want German or French or Russian either.
The value to me is clear. It allows me to use CP in British English, my native language. Most software has this capability and it’s something I’ve come to expect. It’s certainly something I would expect of a modern, business-focused CMS.
Also, I’m sure the absence of certain languages would be seen as a negative to many people considering moving from WordPress.
There are numerous differences between British English and American English, not just different spellings (e.g. litre/liter, colour/color) but also different words (e.g. autumn/fall, lift/elevator, and - worst of all - football/soccer ).
Agree on football/soccer, but, as I understand, en_US is more popular, so, why not to leave it as the default? I see some confusion is coming…
Though, the football/soccer argument is quite strong, maybe I’ll change my mind.
I’m not suggesting that the default be changed to en_GB and in fact, I would suggest it be left as en_US. I think that’s the most common practice and what most people would expect.
As a translator I see en_GB as the primary and en_US as derivate.
That is the reason I am suggesting we use en_GB.
But I see the general consensus is that we should go for en_US as default, so let’s agree on this.
Isn’t the default en_US because that’s what is in the code? And all the translations start from there, because those are the extracted strings?
That’s a very valid point.
Yes, sorry. My initial comment was tongue in cheek. But I would like to see en_GB available as an option.
This is correct.
True, but I can clearly see the value in these additions because they will allow new people to be able to use and understand the software. If ClassicPress strings were written in British English instead of American, I would be able to read it and personally this would not bother me enough to want to change it.
Obviously there is value in adding en_GB since multiple people want it, I was just trying to understand that better on a personal level.
I suspect it’s more of an issue for non-Americans who are aware of the Americanisation of many things (or should that be Americanization?).
Is there any reason not to add en_GB? It seems that Tim is offering to do the work. Are they any downsides to having lots of English versions?
ClassicPress itself is using American English as a default because WordPress was written primarily by American software developers. I understand the linguistic argument for using en_GB as a default, but changing this would involve changing lots of strings in core which doesn’t sound like something that would go particularly well.
classicpress.net has some content using British English because Scott wrote those parts.
I would write Americanization, you would probably write Americanisation… it doesn’t really bother me either way as long as it is consistent.
No reason not to add it, if this is something that makes the software nicer to use and if we can do a decent job of it. I think both of these are probably true now.
I’m more skeptical about this - we probably want to have a better understanding of how translations should flow through from a “base” language to its variants first, and a better understanding of how much difference there should actually be between e.g. en_US and en_CA, or en_GB and en_AU. I know some words are different, but are there really any strings in ClassicPress that should be different?
Otherwise a couple of downsides would be maintenance burden, and that people look at our languages list and wonder “why do we have 3-5 English versions but not commonly spoken language X?”
Yes, not seriously suggesting we go down this road.
Good points. And as an en_AU speaker I’m perfectly happy to go with en_GB. I think as long as we offer en_US and en_GB then we should be able to keep almost everyone satisfied.
I’m happy to help but the more the merrier I think. And I also don’t want to undermine the work that @azurecurve has put into en_GB translations in the past.
Just to throw in a little stone…
How many installations of CP do we estimate as existing? Is it possible to understand where these installs come from in term of country? That would help in understanding which locales are needed vs do we have someone maintaining them or do we need to involve someone.
(I think the inclusion of en_GB is a great example of what kind of debate we should have to gain insight and decide on a locale, this aside from the fact we all agree it will not be used as default since we already have en_US serving as such)