r1303: thisarticle changes

net-carver · 2006-06-29 12:01:40

Alex

Further to my earlier post I can give you some feedback now.

I am running into a problem now with a multi-lingual support plugin I am working on at the moment for Marios. I just grabbed the latest 4.0 from svn and am comparing results of 4.0.3 against it.

Here’s a 4.0.3 snapshot with the test page in English.
Here’s 4.0.3 with “Greek” requested (to our Greek readers, please excuse my translations!)

Everything, including the article titles get switched over neatly when the article body is parsed, so any existing tags that grab article titles from $thisarticle are automatically showing the localised strings.

Here’s the latest dev version, with the differences only being in the non-localised titles.

This is a plugin that is in-development so nothing to worry about there. However, this does seem to be a feature that people are asking for. I think your changes are the right way to go and the solution I had come up with (having a special tag in the article body to do the title localisation) is fairly in-elegant anyway.

Could the dev team consider adding a callback event right at the end of the latest populateArticleData function that we could use to post-process the article data to localise things, before it is returned to the rest of textpattern. That would be a far more elegant way to handle the localisation problem.

Last edited by net-carver (2006-06-29 12:06:28)

graeme · 2006-06-29 12:06:03

net-carver wrote:

Could the dev team consider adding a callback event right at the end of the latest populateArticleData function that we could use to post-process the article data to localise things, before it is returned to the rest of textpattern. That would be a far more elegant way to handle the localisation problem.

Yeah an extra callback event would be a great idea, because at the moment we are having to surround our page and form templates with tags to do the substitute the article data for localised data.

net-carver · 2006-06-29 13:21:00

Alex, Graeme,

have just started going through taghandlers.php and there are some other places where the default tags pull article titles straight out of textpattern table. In those cases we don’t have an opportunity to localise before the tags return their results. Whilst the callback would be a great start, it won’t cover all bases anyway.

Perhaps this could be worked around using a completely parallel article scheme. Hhhm.

Last edited by net-carver (2006-06-29 13:30:06)

wet · 2006-06-29 13:29:52

imho, you will always have to resort to the database.

You can never expect that third party plugins work with i18n schemes which would require reparsing article fields even if core code did so. Think “recent comments”, “related articles”, my wet_article_thumb which uses an article’s title to build the title attribute for the thumbnail image, and so on. The implications are endless.

net-carver · 2006-06-29 13:36:55

wet

yes, that’s why I’m starting to think using a parallel article scheme with some kind of admin management layer, would be a more effective way forward (even if it is sparsely populated in 2nd/3rd language). At least each txp article can then contain all that it needs for one translation (its title would already be localised anyway) then all the plugins should work fine too.

Last edited by net-carver (2006-06-29 13:37:57)

graeme · 2006-06-29 17:21:46

wet, net-carver,

Good points about 3rd party plugins conforming localisation schemes set out in other plugins, I never thought of that when I originally planned gbp_l10n.

I do like the idea parallel article scheme but if you do the same to localise sections, categories, links etc… aren’t you are going to hit problems when you want to use tags like <txp:section_list /> or <txp:category_list />. What will you do then?

gbp_l10n was designed so it’s quite easily extended so you can localise any field of any record in any mysql table.

zem · 2006-06-30 01:15:20

Regarding the l10n plugin: IMHO, the clean way to implement something like this would be to create new tags that display localized content. <txp:gbp_l10n_title />, <txp:gbp_l10n_excerpt />, <txp:gbp_l10n_body />, etc. Rather than relying on assumptions about how <txp:title />, <txp:body /> etc work.

I’m not familiar with the plugin though, so I’m just guessing.

Mary · 2006-06-30 01:28:11

What I don’t understand is why they can’t run parse(). ?

graeme · 2006-06-30 10:22:52

zem, mary

zem wrote:

Regarding the l10n plugin: IMHO, the clean way to implement something like this would be to create new tags that display localized content. <txp:gbp_l10n_title />, <txp:gbp_l10n_excerpt />, <txp:gbp_l10n_body />, etc. Rather than relying on assumptions about how <txp:title />, <txp:body /> etc work.

Mary wrote:

What I don’t understand is why they can’t run parse(). ?

Sure we could have separate tags to output each field but the problems comes when there are other tags and plugins’ tags which haven’t been localised. We can’t expect other plugin authors to do anything different than use the standard <txp:title /> etc…

Yes we can run parse() – my plugin already does. But again we hit the above problem, if any tag fetches data directly from the database it won’t get localised. Where as if there was a callback event in populateArticleData() any tag, whether internal or provided by an additional plugin, could take advantage of localised content if they wanted.

zem · 2006-06-30 23:12:31

Yes we can run parse() – my plugin already does. But again we hit the above problem, if any tag fetches data directly from the database it won’t get localised.

There’s a more general problem here: if any tag works in a way you don’t expect, it won’t get localised.

The internal implementation of tags will change over time, as we fix bugs and add new features. Treat tags as black boxes and you’ll be fine. Assume they work in a particular way and things will break.

Sure we could have separate tags to output each field but the problems comes when there are other tags and plugins’ tags which haven’t been localised. We can’t expect other plugin authors to do anything different than use the standard <txp:title /> etc…

If you mean that other plugin authors have hard-coded their plugins to call the title() taghandler, then that’s a problem with their plugins. They should be designing their plugins to work like this instead:

<txp:foo_mytag><txp:title /></txp:foo_mytag>

Then the user can elect to use your localised title tag instead.

wet · 2006-07-01 06:00:05

If you mean that other plugin authors have hard-coded their plugins to call the title() taghandler, then that’s a problem with their plugins.

Your suggestion implies that all intrinsic tags and all plugins with a richer output (e.g. related_articles, recent_comments) would have to be built with form parsing capabilities. This increases coding and testing efforts for developers, and implementation cost for users.

zem · 2006-07-01 06:30:25

This increases coding and testing efforts for developers, and implementation cost for users.

Pretty much, yep.

The alternative is, we never change anything.

Textpattern CMS

Textpattern CMS support forum

#13 2006-06-29 12:01:40

Re: r1303: thisarticle changes

#14 2006-06-29 12:06:03

Re: r1303: thisarticle changes

#15 2006-06-29 13:21:00

Re: r1303: thisarticle changes

#16 2006-06-29 13:29:52

Re: r1303: thisarticle changes

#17 2006-06-29 13:36:55

Re: r1303: thisarticle changes

#18 2006-06-29 17:21:46

Re: r1303: thisarticle changes

#19 2006-06-30 01:15:20

Re: r1303: thisarticle changes

#20 2006-06-30 01:28:11

Re: r1303: thisarticle changes

#21 2006-06-30 10:22:52

Re: r1303: thisarticle changes

#22 2006-06-30 23:12:31

Re: r1303: thisarticle changes

#23 2006-07-01 06:00:05

Re: r1303: thisarticle changes

#24 2006-07-01 06:30:25

Re: r1303: thisarticle changes

Board footer