Languages bundled in core

Bloke · 2017-11-12 17:46:04

As of this moment – and after much (much) beta testing from a lot of wonderful people who know who they are – we have removed reliance on the RPC server for language provision in the upcoming Textpattern 4.7.0.

I know, right, so what?

Well here’s the scoop:

Language strings are bundled complete with the core download. And yes this makes it bigger.
Better language codes that are more ISO friendly. We had some that had been set wrongly from day one that have now been fixed.
More languages supported out of the box.
The core no longer dictates what languages are available. Adding a language is as simple as dropping it in the lang directory and hitting Install from the Languages panel.
Improved RTL language support.
Removal of outdated strings.
Total overhaul of the Languages panel. No more provision to download from remote server. If you want to update languages, just change the files in the lang directory and hit Update.
Crowd-updated language files are available to download at any time from GitHub.
Overhaul of the pophelp system. Pophelps are served from local files too and open in a floating window instead of a completely separate window. Currently only English pophelp is bundled, but is easily extensible and we’ll bundle pophelps for any language provided to us from the community.
Pophelp support can be turned on/off via a pref. This allows you to use custom inline help instead of, or in addition to, pophelp.
No more separate setup language file, making strings easier to manage in one place.
Fallback strings are loaded with your chosen language so you should never see any core untranslated strings in the UI as long as your choice of fallback language has defined them all.
The fallback language is `en` but this can be overridden in `config.php` if you wish.
Public site language is independent of admin-side language. Each user may choose which of the installed languages to use in their admin side.

We think this change is a positive one and hope you do too. Those of you willing to try out our dev branch, please let us know how you get on with it. And, of course, please supply any translated strings or pophelp to us so we can bundle it with core. Details on how to do this are in the README in the `lang` directory.

BEWARE

To support the new, less opinionated language codes, this is a one-way upgrade. Your string identifiers will be changed in the database on update.

gaekwad · 2017-11-12 19:36:37

Marvellous news!

philwareham · 2017-11-13 08:51:41

Note: I’ll be updating Crowdin soon with the latest string set. That will mean some legacy strings are removed and some new ones added – for every language. Also note: Although Crowdin translations can be downloaded – they are not in the format we use for Textpattern. You should always download latest 4.7+ Textpacks via:

textpattern.com/textpacks-download

etc · 2017-11-13 08:57:46

Hi Phil. Should we submit translations to Crowdin or directly to Github?

philwareham · 2017-11-13 09:03:30

Hi Oleg – you can submit translations either way. Crowdin is simply the easier tool to use for translators and those unfamiliar with GitHub. Either way they eventually get into the core (I just have to move each string manually from Crowdin to GitHub – since we don’t use XML format for Textpacks).

phiw13 · 2017-11-13 09:10:12

I still see raw strings here and there, more so when using a different language. Is that because I only have English (GB) + some other languages active? Do I need to have English installed/actived as well?

Edit: For example, active and use Japanese, then go to the update image edit panel, you’ll see a go_back string next to the Save button.

Last edited by phiw13 (2017-11-13 09:15:39)

philwareham · 2017-11-13 09:15:35

phiw13 wrote #307791:

I still see raw strings here and there, more so when using a different language. Is that because I only have English (GB) + some other languages active? Do I need to have English installed/actived as well?

Yes. English (en non-localized) will be the default language (and default fallback language) for new installs at Textpattern 4.7 onwards. You’ll need that installed (and I think we also set fallback to be unremoveable).

phiw13 · 2017-11-13 09:17:50

philwareham wrote #307793:

phiw13 Yes. English (en@ non-localized) will be the default language (and fallback language) for new installs at Textpattern 4.7 onwards. You’ll need that install (and I think we also set fallback to be unremoveable).

Ah, Ok. I’ll do that later. Need to prepare dinner for Goldfish, Cat, Kids, Wife now.

Bloke · 2017-11-13 11:23:14

philwareham wrote #307793:

You’ll need [en non-localized] installed

Or add:

define('TEXTPATTERN_DEFAULT_LANG', 'en-gb');

to your config.php to retain current behaviour.

Destry · 2017-11-13 12:15:09

Nice blog post opp.

(Ditto for one separately about theming functionality. Why let one dev have all the blog-writing fun.)¹

And remember, the blog is for potential users of Textpattern (i.e. people that don’t waste time hanging around in a forum yet). For example:

Back in the old days you would have had to tolerate this farty situation. But 4.7 is a paradigm shaker! Now when you hop into the lap of luxury, this [xyz functionality] is ready to go.

¹ When each blog post focuses on a single topic, it’s easier to optimize the SEO from top to bottom; front-loading keywords in headers, meta-descriptions, etc and whatever.

phiw13 · 2017-11-13 13:45:51

Hmm, so this is not working as expected – tested on two different installs, both had English (British) as the default; that was the default Setup language at the time.

I install English. Site language and User language are still set to English (British), nothing really changes (well everything was fine, already).
I switch User language to some_other_language. The (some) missing strings are still displayed as raw strings. No changes from before, I think.
I added define('TEXTPATTERN_DEFAULT_LANG', 'en-gb'); to my config.php. Repeat step 2 with same results, tried with ‘en’ instead, idem ditto.

Am I missing something ? (yes – read at the end…)

PS – Preferences > Admin, first line: language_ui as raw string in any language, I don’t see it listed on Github

PPS

Bloke wrote #307804:

Or add:

define('TEXTPATTERN_DEFAULT_LANG, 'en-gb');...

There is Typo there a closing ' after _LANG is missing

PPPS – while typing all this, it occurred to me: I was mostly testing with languages that were already installed, before the landing of this code. Removing the offending languages (tested with Japanese and Farsi), and it appears to work better at first glance. Will test more tomorrow. One thought – what should happen to (missing) language strings for (admin-side) plugins. Would one need to reinstall the textpack for those?

Bloke · 2017-11-13 14:37:17

phiw13 wrote #307807:

There is Typo there a closing ' after _LANG is missing

Ooops, corrected, thank you.

Am I missing something?

Yes. Well, sort of. The strings from the default language will only be merged into the selected language when it’s updated. After the Textpattern upgrade, nothing has changed, except that the lang identifiers are altered in your database to correspond with the files on disk.

We didn’t want to start making decisions on the user’s behalf about which languages to update automatically, so erred on the side of caution and did nothing.

what should happen to (missing) language strings for (admin-side) plugins. Would one need to reinstall the textpack for those?

Currently yes, but I’m going to be testing a cunning patch by makss in the next day or so. Assuming it works — and all signs point towards it being brilliant — once that lands:

Reinstall any plugin that has a bundled textpack. Doing so will store ALL its supported textpacks alongside that plugin in the database, ready for action.
Install/update any language. This will hook into every plugin that has its textpack info in the database and (re)install any strings for the chosen language from the plugins too.

There’s even a callback hook. Plugin authors may need to make a tweak to their textpacks (and I’ll need to update the Plugin Composer) so it always outputs lang identifiers in front of each pack. I might see if there’s anything sensible can be assumed for plugins with missing identifiers. But after that, plain sailing.

Textpattern CMS

Textpattern CMS support forum

#1 2017-11-12 17:46:04