Wedge

I'd tend to say it's more amusing/exciting to only keep the relevant entries.

The load fallback is here to stay, if you ask me. I think most people really prefer to have an English string rather than nothing.

Possibilities to explore...

- add a version number to every single language file. Increase version number whenever a change is made to the English version. Compare current version against English version to determine whether we need to load the English fallback (and warn the admin that their language file is broken.)

- store language files in a serialized array in the database. (or in the cache. I think there's already a cache level for language files. A bad one IIRC, because of the variables involved.) When caching fallback & non-fallback, check whether the English version has some extra strings, and only store those.

That's exactly it. English/British is the most insane language pack to exist because 98% of it is the same as the main English set.I can't see it disappearing either, in which case we might as well remove the internal disable option for it.That's not a bad idea. A little bit tricky to get right, but certainly doable.The variable nature before made it practically impossible to get this one right, and the old language cache was incredibly unreliable, mostly because of Modifications.*.php and the fact that files weren't re-pulled through the cache after modification, so if a mod edited a language file, it never recached it until it naturally fell out the cache.

The real question is whether the benefit outweighs the hassle. I'm not sure what benefit it does actually have to do it for all strings, especially with the way different files reuse strings the way they do.

That said, what we *can* do is put edited strings in the DB, so instead of users having to make files editable through permissions, they just get to put it into the DB.

That's amazing.
That's amasing?

Color.
Colour?

Nope, just amazing.Colour is the correct spelling, of course :P As is centre, serialise, initialise, humour, flavour etc.

Also, I'm sure I mentioned I'd like to do a pirate language pack, which would similarly be based on English :whistle:

Will never forget making my school lose the spelling bee when I was in the 7th grade because they couldn't spell colour and favourite properly. An apology years later didn't help much either.

Do it, DO IT. It would be fun t' imitatin' pirate.

Oh, adding a pirate language pack is something I started to do back in the RC3 days. I just didn't finish it because I was frustrated at the things I'm fixing now.

That, and there was a small problem with dealing with locales, but that's not a problem I have to worry about these days (knowing much more than I did about setlocale 18 months ago)

Weh. Who needs the american way of spelling it anyway? British English and French should be standard!

Yeah, British English should be the only one (no American English at all)!

I'd have to go through and fix a number of strings in the core, and if I did that I'd want to use colour bbc instead of color and so on :/

There is another thing I'd do with this overhaul, actually. There's something that's annoyed me for a long time: the way languages are displayed to users for choosing.

If you have a list of languages, and you list them as English, French, Spanish... you're Anglicising it. It should be the proper language, e.g. English, Francais, Espanol. (Accents included, I just couldn't be bothered typing them)

Now, the reason it's done how it is right now is simply ease of programming and performance: it's easy enough to look up index.*.php files and split the * on _ and upper-case the first letters. That's how you end up with Spanish (or worse, Spanish Es, a construction that's somewhere between meaningless, irritating and unintuitive)

Instead, if you build and store a list, you can actually load the files themselves to get the right string, so you can actually have the files themselves contain a proper language-dependent string holding the proper form of that language's name in that language... can't say more logical than that IMO.

(It would replace the current getLanguages() process, and would cache the value inside $modSettings. I have no problem with only setting it from the admin panel and have the admin panel be the one to set it, so it's only set if the user asks to recache it, or when you add a new language.)

We need a Yoda language. :P

Tempt me, you should not.

Yoda is a not a language per se but a translation.

"No one wants to die. Even people who want to go to heaven don’t want to die to get there. And yet death is the destination we all share. No one has ever escaped it. And that is as it should be, because Death is very likely the single best invention of Life. It is Life’s change agent. It clears out the old to make way for the new. Right now the new is you, but someday not too long from now, you will gradually become the old and be cleared away. Sorry to be so dramatic, but it is quite true."

Yoda:
"To die no one wants.  Even people who want to go to heaven want not to die to get there. And the destination we all share, yet death is.  Ever escaped it, no one has. And as it should be, that is, because very likely the single best invention of life, death is.  Life's change agent, is it.  To make way for the new it clears out the old.  You, right now the new is, but too long from now someday not, gradually become the old and be cleared away, you will.  To be so dramatic sorry, but quite true, it is.  Yes, hmmm."

I know :P From my POV, anything that requires altering a lot of language strings is effectively a language pack candidate.