RFC: author-level language setting in article UI

gaekwad · 2020-10-08 15:52:15

The Textpattern default theme uses the site language setting for its html language declaration, i.e.:

<html lang="en-us" dir="ltr">

This is just fine for a lot of sites. That is, until you have multi-user, multi-lingual sites where individual articles may be written in the author’s native language.

This came about because the demo sites I run are used with a wide variety of languages. Any Managing Editor can install a (new) language pack from the 40+ provided, and proceed to set the site language and/or user language to whatever they choose. The site language is applied to the pages and forms instantly, but articles written as that author are not tagged with that author’s language, regardless of whether they’re in line with the site language.

Considerations:

it doesn’t necessarily follow that the user’s chosen UI language would match what they write in (i.e. an author may be multilingual);
a dropdown menu in the article UI might not be good UX (i.e. too long, unwieldy);
an article might not be written in a language covered by a Textpattern-installed Textpack (e.g. Alicia may write an article in Marathi for a Gujarati website);
potential site breakage if the dir setting attached to the article lang is contra to the global setting;

Given Textpattern’s attention to metadata and accessibility – thanks, Phil – would this be worth investigating further?

Last edited by gaekwad (2020-10-08 15:59:31)

Bloke · 2020-10-08 17:04:41

Yes. Long-term, multi-lingual content is a goal. That will then encompass (probably) a language selector on the Write panel and the ability to translate other content such as alt text.

The problem we have is that (admin-side) language is easy to add to the <html> tag based on the user’s current experience. Multiple users can see the admin side in any language they choose without affecting anyone else.

But content doesn’t (currently) have provision for more than one language. It is set once and all content is assumed to be in that language.

When we get true multi-lingual content, I presume that the ‘site language’ pref will become a ‘default site language’ for anyone who has not stated otherwise. Then content will override that default on an as-needed basis. Thus, if you visit ‘fr’ links you’ll get French content pulled from the database. Same for any other language. But if you visit a non-denominated front-end page, you’ll get it served in the default language.

Bonus marks for cookies and browser accept-language sniffing to intelligently pick a default or remember a previous language so if you visit a non-denominated link you could still be served content the same as the last page you viewed. Not sure about that, but we could try and be clever.

Writing content in a language not installed with a Textpack is possible but “furniture” strings such as ‘Category’ and ‘Posted’ and date formats, etc, would thus be rendered in the site default or best guess language. If a language pack exists for the content being consumed, it’s the admininstrator’s responsibility to ensure it’s installed for a more seamless user experience. And if the language is missing, well, that’s why we have Crowdin :)

Lots to think about, especially the mechanics of letting people view articles to be translated side-by-side, how to associate one URL as being ‘the same content’ as another, just in a different language (and how feed subscribers are served/pinged accordingly), translation workflows linked to article statuses, and how to handle deletions.

The key thing to opening this up is a ‘lang’ column in all content tables, and a database-level way of indicating content equivalency. Then we’re rockin’.

EDIT: to answer the OP, since content is more than just articles, any introduction of ‘such-and-such content is in this language’ needs to be considered for all content types: file titles, alt tags, captions, link names, section names, category names, meta descriptions, tags (when we get them), …

Last edited by Bloke (2020-10-08 17:14:56)

gaekwad · 2020-10-08 17:19:39

Nice one, Stef – well put, as always. Thank you.

etc · 2020-10-08 21:20:02

Would introducing some kind of <txp:author_info type="lang" /> tag help here?

phiw13 · 2020-10-09 00:12:20

etc wrote #326267:

Would introducing some kind of <txp:author_info type="lang" /> tag help here?

I think that would only be of limited use. Author C is possibly fluent in both Spanish and Quechua and write articles in both languages.

–^–^–

In general yes, there should be more power to tag articles (and e.g. image meta information, as noted) with the language used. I’ve used a custom field in the past for that purpose.

I see two possible situations: 1/ fully multi-lingual sites e.g. domain.ltd/en, domain.ltd/sp, domain.ltd/de,…) with all UI, content etc in the same language. Here we need to be have the templates with lang attribute on the root element.
And 2/ a site in language A but with occasional translations of articles or possibly some article in language B, or C or, …. In this case, the lang attribute could go on the actual container (e.g. <article lang="sp">…</article> for the article if it does not match language A; UI and similar site elements would be in language A. Possibly something (an attribute) that can be managed via the <txp:article /> tag?

Bloke · 2020-10-09 07:07:19

phiw13: Yes. The TLD should dictate the language that the content is in, but local tags on that page can override the hint with a dedicated lang attribute to fetch supporting content in other languages if necessary. And fail/throw warning in debug mode if they can’t find one that matches.

colak · 2020-10-09 07:11:21

What happens when the page is multilingual though? On our site I include <div lang="el">...</div>, but I am now wondering if there is a better method.

phiw13 · 2020-10-09 08:23:39

colak wrote #326271:

What happens when the page is multilingual though? On our site I include <div lang="el">...</div>, but I am now wondering if there is a better method.

Most of the page is in English (main site language) and you include some snippet / article / … in Greek? Then what you do is perfectly fine.

Bloke wrote #326270:

So we appear to be in agreement then :-).

Bloke · 2020-10-09 08:49:51

colak wrote #326271:

I include <div lang="el">...</div>

Exactly. Consider this:

<txp:article_custom id="242" wraptag="aside" />

If article 242 is defined (via the dropdown in the Write panel) as German then that will render:

<aside lang="de">
... article content here, formatted as per default form...
</aside>

Note you don’t need to tell it the language: Textpattern will know, and can intelligently apply the lang attribute. Inside the form/container you’ll be able to get the language (e.g. <txp:article_lang />) so you can use it for your own purposes if you want to roll your own wrapper or do something based on the language of the content.

Things get a little murkier if you’re making lists, and I haven’t thought this through yet, but off the top of my head:

<txp:article_custom lang wraptag="ul" label="Content also available in" labeltag="h2" break="li">
   <txp:permlink><txp:article_language title />: <txp:title /></txp:permlink>
</txp:article_custom>

If we’re clever enough to know that the ‘context’ is “the current article” (assuming there is one, otherwise you’ll need to give article_custom a hint via another attribute such as category, author, id, etc) and that this article is linked to a bunch of other articles, then the valueless lang (which could also take values of course, such as lang="de, fr, el") can go fetch all the other articles that are deemed ‘equivalent’ to the one being viewed, and iterate over them to produce:

<h2>Content also available in</h2>
<ul>
<li lang="de"><a href="https://example.org/de/section/article-url-in-de">German: Wie man Freunde gewinnt und Menschen beeinflusst</a></li>
<li lang="fr"><a href="https://example.org/fr/section/article-url-in-fr">French: Comment se faire des amis et influencer les gens</a></li>
<li lang="zh-cn" dir="rtl"><a href="https://example.org/zh-cn/section/article-url-in-cn">Chinese: 如何赢得朋友，影响他人</a></li>
...
</ul>
</aside>

Or something like that (not sure if zh-cn simplified is actually read rtl, it’s just an example to show that the direction can be indicated as such based on known language parameters).

Lots we could do once we know a) what language something is in, b) how it relates to other content that is equivalent.

Last edited by Bloke (2020-10-09 08:51:55)

gaekwad · 2020-10-09 09:09:23

…and given an article (or similar piece of textual content) can be updated – and subsequently ‘owned’ by one of possibly multiple authors – it strikes me that the language stuff should be article-level and not per-author…rather an author of a certain number of stripes could change the language for the content if necessary.

(Thinking out loud.)

Bloke · 2020-10-09 09:39:36

gaekwad wrote #326275:

language stuff should be article-level and not per-author…rather an author of a certain number of stripes could change the language for the content if necessary.

Absolutely. The author has a ‘home’ language that they use the interface in – presumably their native tongue. And when they start to write a piece of content in the Write panel, we can default the dropdown to this same language, for convenience (or remember it for next time they author something).

But they’re free to change the dropdown so they can author any content in any language and indicate, at the content level, what language that piece is in.

For other stuff such as alt text, the only thing we can conceivably do is somehow show a field for each language and one or more people can fill them in.

There’s also the notion of “missing” translations which we should factor in somehow. Like smd_where_used in a way, but showing ‘where fields/articles not translated’.

Last edited by Bloke (2020-10-09 09:41:48)

Textpattern CMS

Textpattern CMS support forum

#1 2020-10-08 15:52:15