[UX] New installation default post and comment i18n

gaekwad · 2014-10-30 10:52:52

Aside from available translation resource, are there technical reasons why the default post and comment shouldn’t be internationalised, with a fallback to the default (English) version if it’s not in the installation textpack?

From a usability point of view, a user can run the entire Textpattern installation process in ~40 languages, but the default post is always English. It doesn’t matter how helpful the default post is, if English is not a familiar language to the user then there’s a abrupt stop. That’s not ideal.

Something like a bunch of new fields in the installation textpack with the language strings for:

default post title
default post url
default post body
default comment author
default comment body

…would be one approach to take.

Thoughts?

Last edited by gaekwad (2014-10-30 10:53:09)

Bloke · 2014-10-30 11:02:57

That’s a very valid point. But doing this using lang strings isn’t going to cut it, as the interface doesn’t internationalise the content of fields, just their labels. Content in the textpattern table is ‘just text’ to Textpattern and it has no notion of language for content.

If you’d like to be cut in on the grand plans I have for improving this situation, drop me a note and I’ll send you the doc for you to tear apart.

gaekwad · 2014-10-30 11:12:33

Bloke wrote #285247:

But doing this using lang strings isn’t going to cut it, as the interface doesn’t internationalise the content of fields, just their labels. Content in the textpattern table is ‘just text’ to Textpattern and it has no notion of language for content.

I ran an install in es_ES as a test. Here’s the thing: the comment invite text is in Spanish (`Comentarios`), and rightly remains so when I switch the locale to en_GB. I presume — and you know I’m not a developer, so bear that in mind — that setup_comment_invite does the magic there.

Last edited by gaekwad (2014-10-30 11:13:19)

Bloke · 2014-10-30 11:31:01

gaekwad wrote #285248:

comment invite text is in Spanish (`Comentarios`), and rightly remains so when I switch the locale to en_GB.

Yes, the default comment invite text is a special case. It’s a pref in the txp_prefs table, and everything in there is subject to translation so it’ll reflect the installed language.

But when you edit the (default, i18n) invite text in the Write panel on a per-article basis, it’s stored along with the article content in the textpattern table, which is then ‘just text’. The other user editable fields (title, body text, custom fields, etc) are all true content and are therefore treated as ‘just text’ the whole time.

Does that sort of make sense?

gaekwad · 2014-10-30 11:32:42

Bloke wrote #285249:

Yes, the default comment invite text is a special case. It’s a pref in the txp_prefs table, and everything in there is subject to translation so it’ll reflect the installed language.

[…]

Does that sort of make sense?

Absolutely makes sense, yes – thank you.

uli · 2014-10-30 14:49:06

And would you guys see severe downsides from using the txp:lang tag in an article, like this:

<txp:variable name="lang"><txp:lang /></txp:variable>
<txp:if_variable name="lang" value="en-en">Hello world!</txp:if_variable>
<txp:if_variable name="lang" value="fr-fr">Salut monde!</txp:if_variable>
<txp:if_variable name="lang" value="es-es">¡Hola mundo!</txp:if_variable>

OK, that’s only the body copy, not the other elements Pete listed, but it’s the main part, the biggest stopper if not really readable.

Bloke · 2014-10-30 15:50:17

uli wrote #285268:

And would you guys see severe downsides from using the txp:lang tag in an article

No downsides in terms of body copy as far as I can tell, except for the fact article #1 would be huge :-)

Two things we have to be wary of here:

It works for body (and would work for excerpt) but won’t work for title. So “Bienvenue a …” etc is not possible.
Having a multi-lingual first article might give the impression that Txp supports multi-lingual content out of the box which, at the moment at least, is not true.

That last point is the biggest red flag for me. Although having this available right now in 4.5.x might seem compelling, I’m concerned that such a first article might imply Txp language functionality that outstrips its actual capabilities. I may be wrong here so please correct me if I’m being ridiculous.

The thing is, true multi-linguality is not actually that difficult to achieve, either in core or, at the very least, to add a framework to enable a proper plugin (or plugin suite) to pop up instead of the long-in-the-tooth and difficult-to-maintain MLP we have today.

There are a few kinks in the theory to iron out yet, so I’d like to garner input from a few folks such as your fine selves on the proposal before I unleash it and see if any benevolent developers will help bring it to reality on Github. If you have a half hour to spare to comb through the document, I really would appreciate it. Drop me a mail if so.

GugUser · 2014-10-30 17:29:02

Hola uli: here the correct ¡Hola mundo! for copy and paste in your example.

;-)

uli · 2014-10-30 18:08:50

Bloke wrote #285270:

[…] I’m concerned that such a first article might imply Txp language functionality that outstrips its actual capabilities. I may be wrong here so please correct me if I’m being ridiculous.

I certainly can’t correct you, I just have a gut feeling that most people would like to be welcomed in their own language. That’s what I’d like to promote.

In my book, having such an article would simply bridge the gap between a multilingual back-end and the English “What do you want to do next” article. It would as little brag about multi-linguality as the possibility to choose a back-end language is bragging about that. Only if users switched their admin language it would become visible that there’s a mechanism that cares for the right language. Without switching the language, reading the article in the users native language is the most natural thing, like for you English speaking folks when you go to the front side of a fresh installation.

Drop me a mail if so.

Will do.

uli · 2014-10-30 18:11:50

Hola GugUser, that’s just a font display thing, I used alt-shift-1 (German keyboard).

GugUser · 2014-10-30 19:54:31

uli wrote #285278:

Hola GugUser, that’s just a font display thing, I used alt-shift-1 (German keyboard).

Ah, it doesn’t work inside of <code>. I didn’t know that. Sorry.

maverick · 2014-10-30 22:33:30

Bloke – did you ever have a chance to look over IonizeCMS’s multilingual implementation?

Interface-wise it is one of the easier/more intuitive important implementations I’ve tried.

Bloke · 2014-10-31 00:11:41

uli wrote #285277:

I just have a gut feeling that most people would like to be welcomed in their own language. That’s what I’d like to promote.

Perhaps you’re right. If we can come up with a way to localise the title, your method is the most viable unless we defer the article content to use textpack strings somehow like Pete suggested. If anyone has any good suggestions on how to do this for real, let’s hear ‘em.

@maverick. No, sorry. There are a couple of CMS solutions I need to check out for various ideas we might be able to pay homage to, and that was one of them. I’ll see if I can make time to check it out, thanks for the reminder.

gaekwad · 2014-10-31 10:24:09

uli wrote #285277:

I just have a gut feeling that most people would like to be welcomed in their own language. That’s what I’d like to promote.

This. As a person with English as a primary language writing English for an audience with English as a first language, it’s disturbingly easy to overlook the multilingual aspect of the web.

Bloke · 2014-10-31 10:44:10

gaekwad wrote #285300:

This. As a person with English as a primary language writing English for an audience with English as a first language, it’s disturbingly easy to overlook the multilingual aspect of the web.

OK, you’re right. Let’s figure out how to solve the internationalisation of the Title and we can move forward.

One option (although slightly hatstand) would be to store the lang string name in the Title of the default post. e.g. welcome_to_your_site. The default template could then use:

<txp:text name='<txp:title />' />

and if we had a new string equivalent in the txp_lang table it’d render the title in the installed language. But it would look odd to have an underscored string as the title, especially as the first article also serves as a tutorial on how to work with Textpattern. It’s not exactly promoting bad practice, but unconventional practice, which might be slightly disconcerting for first-timers.

Any better ways to solve it?

Textpattern CMS support forum

#1 2014-10-30 10:52:52