r1303: thisarticle changes

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.

wet · 2006-07-01 06:36:26

The other alternative is an i18n stub layer in the core code, to which extent ever as gTxt does this for the back end.

graeme · 2006-07-03 12:24:57

wet wrote:

The other alternative is an i18n stub layer in the core code, to which extent ever as gTxt does this for the back end.

Not just useful for i18n/l10n. It opens up many possibilities.

For example. I’m working on a site at the moment for a small newspaper, where there are too many people writing content and it is not possible to expect everyone to upload their articles, mainly because its been written elsewhere so it ends up being uploaded by a different person. I’ve created a custom field for the real author. If the were callback events then it would be able to change the author to the correct person.

Or how about a plugin which wishes to extent the number of custom fields, with a little DOM scripting and a callback event the new fields would be available to every plugin author to use.

Two simple examples, I’m sure there are many more elaborate possibilities and advantages to this.

Saying that, I can see why sometimes you wouldn’t want to have modified content. How about having an extra attribute to populateArticleData() something like:

function populateArticleData($rs, $allow_override = 0)

It won’t change to the current behavior unless the developer knows about it. It could even be a preference letting the site admin decide wether or not to to allow it.

zem · 2006-07-04 00:29:55

If the were callback events then it would be able to change the author to the correct person.

There are already callbacks you can use to do this when an article is saved. And a plugin that lets you change the article author.

Or how about a plugin which wishes to extent the number of custom fields, with a little DOM scripting and a callback event the new fields would be available to every plugin author to use.

Also already possible.

I don’t see how either of these are related to the i18n issue.

Textpattern CMS

Textpattern CMS support forum

#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

#25 2006-07-01 06:36:26

Re: r1303: thisarticle changes

#26 2006-07-03 12:24:57

Re: r1303: thisarticle changes

#27 2006-07-04 00:29:55

Re: r1303: thisarticle changes

Board footer