Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
Front side theme - text direction
OK, so I’ve done a bit of work on Textpattern 4.6dev to make it a bit better in RTL languages. Still more to be done but it’s a start.
That got me thinking… we have a <txp:lang /> tag to dynamically set the language on a public theme, but no way to set text direction as far as I can see, apart from a user hard coding the HTML tag into a template (which isn’t dynamic). Maybe a new <txp:lang_dir /> tag would suffice?
Offline
Re: Front side theme - text direction
philwareham wrote:
OK, so I’ve done a bit of work on Textpattern 4.6dev to make it a bit better in RTL languages.
And it’s a grand start, nice one.
no way to set text direction
Yeah, it’s kind of lacking. The <txp:lang /> tag just reads the language as set in the prefs, which is a discrete value. The text direction isn’t available as a preference anywhere so we could either:
- imply it from a lookup table.
- add a new preference, although if that route was followed it’d be better if it made an educated guess at the direction if the language was changed.
- read the lang translation file for the chosen language, which has an entry indicating the direction, and default to LTR if missing. That’s what the admin side does now.
Providing we can keep up with any new languages that might pop up (probably doesn’t happen all that much, but in the interests of world stability) that would work up to a point. The only sticking point as I see it is that, in some cases as mentioned in that link above, for example:
Azeri can be written in any of the Latin, Cyrillic, or Arabic scripts. When written in Latin or Cyrillic scripts, Azeri is written left-to-right (LTR). When written in the Arabic script, it is written right-to-left.
If we had different translations for each of the scripts of a particular country — I think we may have one or two like that already, but I’d need to check — then reading the translation file and obtaining the direction from there and presenting it as a tag/attribute would be a winner.
On a related note, one thing I’ve been toying with is doing something similar to what I did for a completely unrelated system recently. I based the language mechanism on a mashup of Textpattern’s concept of a file per script containing name-value tuples and MLP, but took it a shade further. Since I decided to use XML as the transport (although JSON or equivalent would have worked equally well) I could define the master list of available languages like this:
<languages>
<lang id="en-gb">
<label>English (UK)</label>
</lang>
<lang id="en-us">
<label>English (US)</label>
</lang>
<lang id="de-de">
<label>Deutsch</label>
</lang>
<lang id="fr-fr">
<label>Français</label>
</lang>
<lang id="zh-cn" dir="rtl">
<label>中文(简体)</label>
</lang>
</languages>That enables the direction, language name, and ID to be available to the system as a tag, or whatever and gives a nice ‘lang list’ dropdown path. Then, each language file was defined as follows (this one is the en-gb file):
<l10n>
<item id="preamble">Welcome to thingamybob. Please read the licence file.</item>
<item id="save_database">Save database</item>
...
</l10n>I’m not saying I’d do that in Txp, and I’d probably have simplified this entire thing if I implemented it again, but the crucial difference is that, to avoid swathes of language string repetition, a language could be defined as follows. This one is for en-us, for example:
<l10n extends="en-gb">
<item id="preamble">Welcome to thingamybob. Please check the license file.</item>
</l10n>so the ‘new’ language inherits all the nominated language strings but replaces any differences in spelling by overriding the relevant strings (such as the spelling of ‘licence’ here).
There’s no reason that we couldn’t figure out some similar way in Textpattern, within the current mechanism, to offer the notion of ‘language A extends language B’. Perhaps the only major difference between some scripts might be the text direction or a few choice strings as in the example above. It potentially keeps down the work of translators (Brazilian might use Portuguese as a base, but with minor differences: I don’t know as I’m not a polyglot). It may also give more flexibility to define language direction on a per-script basis, and give us the ability to offer Txp in more specialised languages, without considerable effort from the international community. The slight downside is that if a base script is altered, the inherited script also changes any non-overridden strings, which might not be what we want, and it gets interesting to manage updates as we’d need to check the dependency tree to see if things have been modified.
Not sure if it’s worth the hassle, but as you’re going through the LTR/RTL thing now it’s a good time to see if anything can be done to improve things in the entire language arena. Just thinking out loud really.
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
Re: Front side theme - text direction
Hi Stef,
The whole multi-language thing in Textpattern is severely lacking for a CMS – that’s not a criticism of anyone or their work, it’s just the way Textpattern was built to start with and never changed. Anything that you can do to improve that would be great work in my eyes. Can anything you’ve learned from working the MLP be brought into the core?
I had to dump Textpattern on a couple of our bigger client sites because they wanted to go multi-language – had to use Drupal instead (and I really dislike Drupal’s complexities and messy HTML output).
Off topic, another thing Drupal really gets right is article revisions. I like that function.
Offline
Re: Front side theme - text direction
philwareham wrote:
but no way to set text direction as far as I can see
There is:
<txp:text item="lang_dir" />Then just fix the bloody definitions so that all languages define the direction, and stop adding duct tape. That shit makes me red.
That is the entirely wrong place for such patch. Even inside gTxt() would work better, or you know, within the Textpack installer. K? But really, the fix should be done at the source, in the definition.
Bloke wrote:
to offer the notion of ‘language A extends language B’
Its about 8 lines of code with our styling. Just add a new variable to the parser, and then recursively run a new installer instance in the install_textpack on the given language when running to new ‘extends’ variable in the resulting array.
philwareham wrote:
Can anything you’ve learned from working the MLP be brought into the core?
Yes. By rewriting Textpattern so that it has actual routing support, ORM (this is a must) and views, turning it system where you ideally feed the content to template rather than template requests content any way it wants. That will finally allow us to know how the content will be mapped and we can serve alternate localized versions of pages by changing the served data. This will also allow plugins to join the fun (take advantage of the localization, and serve their own localized content).
Meaning, you can’t do good MLP with Textpattern. It becomes a mess. And finally when you do add it, Textpattern as a whole becomes more complex to use. First even to think about you would have to create a new Admin interface.
At earliest to even implement something like this would be Textpattern 5.0.0 since, the changes would break backwards compatibility, even if we did go the lame route and implement localization in the Database Adapter end (reads are directed to language prefixed table when language environment constant is set, if the table, or row doesn’t exist, reads are directed back to the default table).
Last edited by Gocom (2013-08-14 13:05:30)
Offline
Re: Front side theme - text direction
Right.
Well, I’ve just gone through the RPC server and corrected the text_dir string throughout all languages so I guess you can lose that ‘duct tape’ if you want (any new languages added to RPC would default to ‘ltr’ anyway unless someone manually edits it to something else).
There is an error in Ελληνικά language though, seems to be 2 entires in the RPC database for text_dir so someone with database access will need to fix that.
Offline
Re: Front side theme - text direction
Why again are those translations on a server and not in a vcs (on GitHub, or in the main SVN, in the lang directory)?
These translations really need to public and anyone should be able to send in pull requests. Plus we could, well, tie the translations to specific Textpattern versions so a specific version gets the correct translations.
I don’t really like the whole server thing at all. I would rather package the translations to the download on releases.
Offline
Re: Front side theme - text direction
Who knows. I just use the tools I’m given.
The RPC server is a mess anyway, just look at the way pophelp files are displayed in Textpattern – we should just be serving XML files via JSON or something like that, not these horrible external HTML pages with their own stylesheets and stuff.
Offline
Re: Front side theme - text direction
I 100% agree having the language files on GitHub would make it very easy to keep them up to date. So many missing translation strings in the RPC at the moment.
Offline
Re: Front side theme - text direction
philwareham wrote:
pophelp files are displayed in Textpattern – we should just be serving XML files via JSON or something like that
OT: Ah, that reminds me. I did that aeons ago — added a mechanism to serve JSON pophelp content — but I never sent it to Robert to add to the RPC server. I’ll dig it out and post it to you three for review. Whether we continue with it or not long term is another debate.
Last edited by Bloke (2013-08-14 13:51:31)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
Re: Front side theme - text direction
I’d vote to dump the server completely and go with a more modern way of providing languages like Jukka has suggested. The ‘welcome to Textpattern’ article when you first install always being in English is also bad. If I wasn’t English I’d be a bit put off by that straight away.
What other purpose does the RPC server serve, anything apart from providing languages/help files?
Offline
Re: Front side theme - text direction
I’ve started collecting the translation for a GitHub repository. Its going to go live soon. After which I’m going to write tests for the languages and CI using Travis. Tests will prevent bad pull request being merged and makes sure all translations contain all strings.
philwareham wrote:
What other purpose does the RPC server serve, anything apart from providing languages/help files?
- “There is new Textpattern version available” message on Diagostic report (static message)
- Pinging home
Offline
Offline