Add lang attribute to <txp:text />

gaekwad · 2015-07-14 09:06:44

txp:text doesn’t appear to have any option to specify an alternate language. If >1 languages are installed, for example on multi-lingual sites, I would love to have the option to fine-grain control output of button text, messages etc. Something like this:

<txp:text item="older" lang="es-ca" />

Last edited by gaekwad (2015-07-14 09:23:12)

Bloke · 2015-07-14 17:33:30

Fine idea. If only more than one language was downloaded to the public site :-(

But there’s nothing to stop the lang attribute firing off a database request for either:

individual strings on an as-needed basis (caching them in textarray for future requests on the page), or
(probably better, if more network traffic) fetching the entire array for that language — and caching as above — thereby cutting down on future requests. The rationale being that the fact you’ve called the thing with lang means you’re quite likely to want other strings in the same language. Future requests for the same language would then just use the downloaded array directly.

On the surface, seems like a worthy addition and another stepping stone towards multi-linguality. If you fancy flexing your PHP muscles, be my guest. Failing that, raise an issue and I or some other benevolent contributor can look into it.

etc · 2015-07-14 18:24:46

I’d say 2, because how many users are well acquainted with item attribute values of <txp:text /> tag? Probably, some <txp:lang /> switcher would be easier to use.

Bloke · 2015-07-14 18:39:52

etc wrote #293182:

I’d say 2, because how many users are well acquainted with item attribute values of <txp:text /> tag? Probably, some <txp:lang /> switcher would be easier to use.

Interesting. Are you proposing to use that tag instead of the lang attribute to load the languages from the DB to the public side?

I was intending to hijack <txp:lang /> at some point for use in a container. Maybe, I dunno, inside <txp:lang_list> or something, which would return a list of installed languages for you. So you could display information about the current language inside the container / make a select list lang switcher, stuff like that.

Right now, it just returns the 2-letter code of the “current language” (monoglot) but I’d intended to add an attribute — like type or item or something — so you could get more info from it when used as a single tag. But it would return info about the “current language” (polyglot) from the list inside the <txp:lang_list> container. Is this compatible with your vision for its use in Pete’s proposal?

etc · 2015-07-14 19:36:27

Bloke wrote #293185:

Are you proposing to use that tag instead of the lang attribute to load the languages from the DB to the public side?

Oups.. I’ve forgotten that <txp:lang /> already exists. Yes, it could accept some lang attribute to load (and cache) language strings, either inside its $thing (if turned into container), or globally (in single tag mode).

I was intending to hijack <txp:lang /> at some point for use in a container. Maybe, I dunno, inside <txp:lang_list> or something, which would return a list of installed languages for you. So you could display information about the current language inside the container / make a select list lang switcher, stuff like that.

Right now, it just returns the 2-letter code of the “current language” (monoglot) but I’d intended to add an attribute — like type or item or something — so you could get more info from it when used as a single tag. But it would return info about the “current language” (polyglot) from the list inside the <txp:lang_list> container. Is this compatible with your vision for its use in Pete’s proposal?

I think yes, if lang attribute is unset, it could just return some info, without changing the language. Setting lang could allow for things like

<txp:lang_list>
	<txp:lang lang='<txp:lang />' />
	In <txp:lang type="full_name" /> "older" is "<txp:text item='older' />"
</txp:lang_list>

And Pete’s proposal (e.g. <txp:text item="older" lang="fr-fr" />) would be equivalent to

<txp:lang lang="fr-fr"><txp:text item="older" /></txp:lang>

I don’t know how many people use individual <txp:text /> tags. It seems more logical to change all language strings at once, but I have no clear idea yet.

maverick · 2015-07-15 01:48:43

With fear and trepidation, can I muddy the waters? (I know – groans abound)

With the move to multilingual capabilities, I am wondering if, in theory (I don’t have a real life use case at this point), a <txp:if_lang> tag would become valuable.

Something like

<txp:if_lang isocode="es" >
<txp:text />
*or alternately*
<other special content />
<txp:if_lang />

(Quietly returns to the woodwork)

Last edited by maverick (2015-07-15 01:50:16)

etc · 2015-07-15 09:10:34

maverick wrote #293208:

With the move to multilingual capabilities, I am wondering if, in theory (I don’t have a real life use case at this point), a <txp:if_lang> tag would become valuable.

Stef is your man, but if <txp:lang /> could be used as container, rather than a new tag I would suggest

<txp:lang lang="es" >
	<txp:text />
<txp:else />
	<other special content />
</txp:lang>

gaekwad · 2015-07-15 11:30:53

I am absolutely not married to the OP idea/route of a new attribute.

…and – frankly – etc’s far better at this kind of thing than I, so I’ll defer to his idea above this reply.

etc: are your skills suitable for switching lang to a container rather than just a single tag? I’ll pay you in jelly beans.

maverick · 2015-07-15 13:58:52

etc wrote #293225:

if <txp:lang /> could be used as container, rather than a new tag I would suggest

<txp:lang lang="es" >...

etc – a much better suggestion!

etc · 2015-07-15 15:12:42

My dear Lords, it’s not that I wouldn’t, but:

Stef has some plans re multilingualism, he would do it better and faster;
Loading language strings is the longest (by far) db query on a typical page, this tag shouldn’t be taken <txp:lang lang="fr-fr">à la légère</txp:lang>.

Bloke · 2015-07-15 20:06:04

etc wrote #293254:

Stef has some plans re multilingualism, he would do it better and faster;

Plans are just plans until someone makes them happen. I have a doc, sure. It has some logical and functional holes in it, I’m sure. I’ll rejig it in light of recent multi-lingual conversations on the forum and publish it if someone thinks they might be interested in improving it and/or putting some code towards it. Like Themes, I don’t think it’s that big a job if it’s broken down and the goals are simplified, with plugins being allowed to add supporting functionality as the end game.

Loading language strings is the longest (by far) db query on a typical page

Yes, and it’s going to get worse as more strings are added and sites are delivered in multiple languages.

But we have a unique opportunity here with the next batch of 4.x upgrades. Since we intend to phase out reliance on the RPC server for both language strings and help, and find a better way to manage languages (e.g. by bundling all language packs and help content with Txp in the download or making it a one-click job to grab a pack and install it from a central location for that version of Txp) then we potentially have a few wins at our disposal:

We could strip out all legacy strings that are no longer used in the next release. That’s not easy but a simple support utility to grep through the distro and find gTxt() calls and compare them to any given language might get us 90% of the way there. I do this in ied_plugin_composer to scan for potential Textpack strings in plugin code, but it misses some that are programmatically generated (e.g. gTxt($event . '_something')). The language packs keep getting bigger, even though there’s a lot of cruft to support older versions back to the gamma days. There’s no real need to keep doing that if we maintain some kind of version info against strings so packs can be built for the strings only in that version of Txp.
We could find a better way to load lang strings on the site. Examples (not necessarily all feasible or desirable) are:
- Scanning for strings and only loading the ones in use on a page.
- Loading strings on-demand and caching them.
- Using the disk more by loading them all on first page request and caching them so that future requests on subsequent pages are disk bound if those strings exist. Plugins could also play here too with the same built-in mechanism.
- Bypassing the DB entirely and using the distributed packs for all content, only deferring to the database if a string is not found (e.g. a plugin string request, which could then be cached too).
- …

There are other ways we could improve things here for both optimisation and workflow improvements. If anyone can chime in, float ideas, run with this, put some code to it, anything, it would really benefit everyone.

makss · 2015-07-16 04:58:26

<txp:text item="older" lang="es-ca" />...

I also encountered this problem when you run a multilingual website

My first thought was to use the tags Texpattern (via a plugin), as described by you. But the code of forms becomes difficult to read and very difficult to edit them later. Therefore, a simple wrapper was written which makes replacing {{some_words}} to the desired language. That is, the page template and the forms used simple {{older}}.

For explicit language, I would suggest {{older:es}} or {{older:es-ca}}

Upd: This approach proved to be convenient for me. I have used TxP tags:
{{sec_short_<txp:section />}}
{{sec_long_<txp:section />}}
{{sec_description_<txp:section />}}
{{sec_keywords_<txp:section />}}

Last edited by makss (2015-07-16 09:34:24)

Textpattern CMS

Textpattern CMS support forum

#1 2015-07-14 09:06:44