Skip to main content ↑ ↓
Thoughts on language editing? Started by Arantor · · Read 15196 times 0 Members and 1 Guest are viewing this topic. previous topic - next topic

Thoughts on language editing?

I'm mostly curious... are there plans to upgrade/refit the language editor that's inherited from SMF? More curiously, do those plans involve editing the language files directly?

I ask primarily because it's what I've been doing with Wedge, and it's been an interesting ride thus far, and I'm willing to share notes on everything I've done and its consequences :)

Re: Thoughts on language editing?

Reply #1 –

This is a serious problem. We haven't chosen yet the way to go, and I have initiated a repository for language files (https://github.com/elkarte/languages). Remaining to see what we can and want to do.

Mainly, the option is to use a git backend (ema's proposal), for a wiki-style of editor.

The initial storage (not editing) is: backend based on git, version the files as per release/milestone. The initial diffs with SMF files are not very significant content-wise IIRC.

As a side note, my personal work and preferences on language editing is not close to a solution yet, for various reasons, so that's moot for the moment.

As a general route however, on language editing/building: we would prefer to use git/wiki (along the lines mentioned above), meaning base the solution on standard version control systems, not custom ones; and build around them the interface for translators.

I appreciate if you're willing to share your experience and path taken. The problems here are interesting and challenging, to say the least. :)
The best moment for testing your PR is right after you merge it. Can't miss with that one.
 

Re: Thoughts on language editing?

Reply #2 –

I wasn't even getting into the translation aspect, simply the core matter of allowing admins to edit language files locally.

The whole task of a master repository for language files is a whole separate ballgame, though I would imagine something similar could be usable.

OK, here's the deal that we have. There are our old friends the language files, which are array additions to two globals. I haven't changed that fact, I see no real reason to do so. But what I have done for the most part is phased out any variable use inside them, e.g. injection of $context, $modSettings and so on into the strings. It's unnecessary and overly fragile, so they're all replaced with sprintf calls or other str_replace injections depending on context (e.g. email templates)

After that, we maintain a table called language changes, which breaks down by theme id (in case themes provide their own ThemeStrings file), language file, language variable ($txt or $helptxt), entry in said variable and the new content. When a language file is requested, an attempt is made on a local cache, if found that will be used, if not we temporarily switch out $txt and $helptxt, load the language file, query the DB for any changes, then apply the result into cache. Note that the caching mechanism is file based but intended to be significantly longer-term than the usual file cache.

I should also add, some time ago we changed the fallback procedure so that English is always loaded first as a fallback, one of the things I'm going to do is take the English, then the other language, then DB changes, and cache *that*, something not currently done. The other benefit is that I'm planning to add languages 'based on' languages, or language variants. That way, English (UK) is only a tiny thing because it just inherits from English (US) and applies its own changes, with some of the Portuguese and Spanish variations for example being attended to in much the same way.


As far as a master repository goes, I actually envisage much the same thing happening as with the local installations, but with additional information a la wiki, storing each revision of a string, who made that revision, when it was made, then having a batch process be able to dump language packs.

Re: Thoughts on language editing?

Reply #3 –

QuoteThe other benefit is that I'm planning to add languages 'based on' languages, or language variants. That way, English (UK) is only a tiny thing because it just inherits from English (US)
Good idea, but you've got it plumbers crack about. :D
Master of Expletives: Now with improved family f@&king friendliness! :D

Sources code: making easy front end changes difficult since 1873. :P

Re: Thoughts on language editing?

Reply #4 –

Given that the base SMF package is English US and there are more English US users in total than there are English UK users, I just had to suck it up ;)

Re: Thoughts on language editing?

Reply #5 –

Quote from: Arantor – Given that the base SMF package is English US and there are more English US users in total than there are English UK users, I just had to suck it up ;)
Don't forget: germans learn the UK version in school, not the US sh*t  ;) I believe this suits for most european countries  :P
Thorsten "TE" Eurich
------------------------

Re: Thoughts on language editing?

Reply #6 –

Huh, maybe Nao's the exception then since he uses the US version for everything :/

Also, the language editor rewrite is really kicking my plumbers crack. I can't find a nice way to present it to the user, there's just too much stuff in one hit.