Plugin Requests

graeme · 2006-06-26 08:04:53

marios wrote:

Just another notice on that. Could it be done to have a full non-messy URL-scheme ?

Yes. I have got full non-messy URL scheme working locally.

It requires an currently unreleased version my gbp_faux_static plugin. My intention was to always to have gbp_faux_static managing the urls requests and gbp_l10n managing the localised content. Keeping the two roles as separate plugins but working together.

jakob · 2006-06-26 20:48:27

marios wrote

Basically I want the possibility of complete parallel content architecture with a symmetric URL scheme e.g.: www.example.org/en/section/title/ and www.example.org/el/section/localized-dyrified-title/

From the backend this needs to be visible possibly from one pane. For instance the two language version titles need to be visible next to each other also from write>articles and so on. And article IDs should be identical.

There’s a parallel approach in book publishing:

One way arranges all the a-language pages from the beginning and all b-language pages from the back turned on it’s head (you turn the book around to read in the other language).
The other way has the same page in a-language on the front and b-language on the back of each sheet.

Your suggestion is what I’d call the single sheet of paper with front and back in different languages. I guess per language you’d need to add all – or at least some – of the existing article fields to the txp-database per article to achieve this. And then you’d need to build a link scheme for getting one or the other language, and then the permlink, search, category/section filters, next/prev to call the right article, etc.

As far as I’ve understood ggbb, he’s (she’s?) put both languages into the article body and article excerpt, then separated them with a marker, and the method displays either what’s above the marker or below the marker depending upon what language is set (with a cookie if I’m not mistaken).

The first method would be very cool, particular if you could simply ‘flip’ the article language, but I imagine if you want the entire functionality of txp to work in both languages it’s a complex job. It might be easier to achieve if one were satisfied with perhaps just some of the fields, e.g. title, body, excerpt, url

net-carver wrote:

You mentioned a scheme Bastian has to do this, is there a link to anything for that?

Steve, he described it a bit on his description of samisdat.org in let’s see yours. As far as I have understood him, it works using a pass-through method and a parallel article in the other language in another hidden section. The German-language article is used for all txp functions, but when the lang=en variable is set to english, then instead of showing the title and body from the German article, it pulls them in from another parallel article in English and displays them. The ID of the parallel article can be stored in a custom field. As a result the categories, section, url-scheme, custom-fields etc. all remain in one language and none of the txp-core needs changing.

grame wrote:

I’ve got a multilingual plugin which does stuff like this.

Sounds great, will have a look.

<small>Sorry for all the quoting, but this thread has several topics running parallel.</small>

maniqui · 2006-06-26 22:33:09

hi all

I would like to request a plug-in that could be named something like: Random Comment.
Some ideas and desired attributes for the plug-in

to output a random comment from a given section (“section” attribute)
to output a random comment from some specified articles ids. Example: <txp:random_comment id="7,15,24" />
would be nice if it could accept the use of article forms. This way, the output can be customized to include permanent links to the article, the title of the article, etc.
also, a limit attribute, so you can have a list of random comments, for example, 3 random comments…

One possible use: random product reviews.

I think a useful implementation for this requested plug-in could be in a site that sells products and where comments are more like “product reviews”.
So, you could have at the home page or at the section front-page a random comment (review) from one of the products.

Well… that’s all!

marios · 2006-06-26 23:34:16

jakob wrote:

marios wrote

Basically I want the possibility of complete parallel content architecture with a symmetric URL scheme e.g.: www.example.org/en/section/title/ and www.example.org/el/section/localized-dyrified-title/

From the backend this needs to be visible possibly from one pane. For instance the two language version titles need to be visible next to each other also from write>articles and so on. And article IDs should be identical.

There’s a parallel approach in book publishing:

One way arranges all the a-language pages from the beginning and all b-language pages from the back turned on it’s head (you turn the book around to read in the other language).
The other way has the same page in a-language on the front and b-language on the back of each sheet.

Your suggestion is what I’d call the single sheet of paper with front and back in different languages. I guess per language you’d need to add all – or at least some – of the existing article fields to the txp-database per article to achieve this. And then you’d need to build a link scheme for getting one or the other language, and then the permlink, search, category/section filters, next/prev to call the right article, etc.

As far as I’ve understood ggbb, he’s (she’s?) put both languages into the article body and article excerpt, then separated them with a marker, and the method displays either what’s above the marker or below the marker depending upon what language is set (with a cookie if I’m not mistaken).

I have been explained about this, and I thought , that it would be a problem, since the excerpts are such an important Element for the Information Structure nowadays, Teasers, etc, …
Now , that I come to see a little the complexity of the matter, I am reconsidering my first requirements and try to understand if the sacrifice of the excerpt would be a big problem.

The first method would be very cool, particular if you could simply ‘flip’ the article language, but I imagine if you want the entire functionality of txp to work in both languages it’s a complex job. It might be easier to achieve if one were satisfied with perhaps just some of the fields, e.g. title, body, excerpt, url

Definetely, yes, haven’t thought about the categories yet.

net-carver wrote:

You mentioned a scheme Bastian has to do this, is there a link to anything for that?

Steve, he described it a bit on his description of samisdat.org in let’s see yours. As far as I have understood him, it works using a pass-through method and a parallel article in the other language in another hidden section. The German-language article is used for all txp functions, but when the lang=en variable is set to english, then instead of showing the title and body from the German article, it pulls them in from another parallel article in English and displays them. The ID of the parallel article can be stored in a custom field. As a result the categories, section, url-scheme, custom-fields etc. all remain in one language and none of the txp-core needs changing.

That looks a little difficult to handle for any other than admin.
But thanks a lot for explaining this so precisely.

grame wrote:

I’ve got a multilingual plugin which does stuff like this.

Sounds great, will have a look.

I’ll take a look also into this, I’ll probably set up a testing Site in the next couple of Days. Grame has stated that if Steve takes over the coordination (In case his code can be used, that he would like to participate in some way to evolve this, something like a little on the outside, since he has little time, ggbb hasn’t expressed any opinions here yet, so what remains is to track down, what can be done without a lot of headache, what would be desirable from a point of view of extensibility,for future evolvement on this and to see may be, if some other apparently significant parts have been forgotten.

I am also willing to test along, so we can collect some evaluation data and take notice of it.
I’ll try to think through it, study also the other resources that Destry mentioned previously, and make some Notes this weekend.
Steve had claimed this pledge, so he can take over the coordination of this project.
The cost still needs to be estimated, but first we have to find a common denominator, to find out what is reasonable, what is stable, what is simple to manage for small-scale clients, and what could serve as a modular approach for further evolvement without hacking the core into pieces.
Steve seems to be able to perceive all these questions quickly.

bq.<small>Sorry for all the quoting, but this thread has several topics running parallel.</small>

Not a big Deal.

regards, marios

Last edited by marios (2006-06-26 23:38:21)

net-carver · 2006-06-27 04:20:49

All,

to let you know the state of play as I currently understand it.

I’ll break the problem into these areas…

Admin interface
Language detection/switching schemes
Translation storage

I consider the admin interface to be possible no matter which of the language detection or data storage schemes are picked, so I will not address it here. You can always download and try out Graeme’s plugin to see what he has done in the admin interface.

I also want to avoid the URL schemes in this post, more can be said later. There are several I have seen now and I think that something useful can be worked out.

The main area I would like to open for discussion is the data storage model. I’ll tell you what I have considered. There are three possible architectures being proposed for the multi-lingual support. I have given some thought to them all but would appreciate your input.

Before going on, we must make a distinction in terms or we will get confused. When I am referring to the data entity that TXP calls an article (that’s what you see when you hit the content>write tab) I will call it a TXP-article. In a mono-lingual setup, one TXP-article holds exactly one article. But that is not necessarily the case in a multi-lingual setup. So we need to widen the definition of article to include the original author’s idea captured in a set of translations plus all the meta data, that the author and the translators produced.

With that said, here are the three schemes I have seen proposed…

Scheme 1: Use “Parallel” TXP-articles.

This scheme maps an article to a set of TXP-articles where each TXP-article holds exactly one translation and its meta-data.

This scheme has been cleverly implemented by Bastian.

Advantages…

Uses existing TXP tables, nothing extra needed.
Search and feeds should work no problem.
Uses existing admin interface
Each translation has a full TXP data set, allowing custom keywords, author meta etch per translation.

Disadvantages…

It subverts the current semantic model of TXP 4.0.3. Each TXP-article is no longer a true article but merely a translated fraction of the whole data set that makes up an article.
Requires a custom link scheme to track members of the set of TXP articles that make up the translated item.

Scheme 2: Master TXP-article with a custom store for translations.

One article is mapped to one TXP-article + n custom table entries.
Used by Graeme with an nice implementation of the admin interface.

Advantages…

Easy to understand.
Easy to provide an admin interface.

Disadvantages…

Translations do not have a full TXP data set. This can be addressed but then, taken to extremes, it is similar to scheme 1.
Closer to, but still subverts the current semantic model of TXP. Each TXP article is no longer a true article but a translated fraction of the whole data set.
Requires a scheme to pick out the correct translated items from custom store.
Out-of-the-box search and feeds potentially broken on translated versions.

Scheme 3: Packed TXP-article + new tags.

This scheme includes all translations in one TXP-article.
Used by GGBB and myself.

Advantages…

No changes or additions to the TXP tables needed, one TXP-article holds the entire set of translations, but not necessarily all the meta data needed, so it’s almost an article (but not quite!)
Search and feeds should work.

Disadvantages…

The title field has to be handled specially.
Requires a new, language aware conditional tag to section the body and excerpt field and provide the correct title.
Requires more admin interface work to make it simpler to use, the body and excerpt can get crowded in the current write tab.
Some key data must be shared across translations. (Example: meta keywords/custom fields).

That’s the theory anyway!

Bastian has a working site using Scheme 1.
Graeme has a plugin that does a lot of scheme 2 and is really well developed on the admin side.
GGBB has apparently implemented Scheme 3 on a site and I have a working ‘skeletal’ plugin that uses scheme 3 on my local host.

Why I chose to explore Scheme 3.

Firstly, I think that Scheme 1 has lots going for it. But in this version of TXP at least, there is a lack of native support for the grouping for articles by language (You can specifically choose to structure your sections or categories to construct a method to do it) but it’s not included in the semantics of the TXP model. Scheme 1 would be my scheme of choice if such a group-by-language feature were inherent in TXP—but it isn’t, so I didn’t want to confuse end users (free-lancers, writers, editors or publishers) with having to learn that an article is not an article, only a translation! (Bastian what do you think? You have implemented this, do your clients get confused by that feature or do they learn to live with it?)

I didn’t like Scheme 2 because it didn’t support many of the basic TXP features out of the box. Searching and feeds would probably only work on the default translation held in the “anchor” txp-article. It also requires a custom table.

So I mainly focused on Scheme 3 because it works with TXP 4.0.3’s data model. This scheme has the closest match of a TXP-article to an article, with all its translations and most of its meta data.

There may be other schemes or variations on the above. I think the best scheme to chose depends heavily on the native language support and data model provided by TXP.

As long as an easy-to-use admin interface is made available and you don’t need a full set of per-translation meta data, I currently consider scheme 3 the best match for TXP 4.0.3. My second choice would be scheme 1.

If you need a full set of meta-data then perhaps scheme 1 is better.

Any observations from the field folks?

Edit: I have a trial plugin working on my local host so I hope to use it to get a better grasp of the scope of the problem. There have also been a few other developments that might change the way this is approached.

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

net-carver · 2006-06-27 05:24:19

jakob wrote:

Steve, he described it a bit on his description of samisdat.org in let’s see yours.

That’s great, thanks Jakob! I think I understand Bastian’s basic method and I like it very much. Some of the things he is doing are very similar to my experiments here and are similar to the way Graeme does the localisation in his plugin.

net-carver · 2006-06-27 07:24:28

Mary,

I’ll take on the multi-lingual request. I might not end up writing all of it but I’ll try to co-ordinate what I can and deliver something that is useful to Marios.

jakob · 2006-06-27 07:25:44

Very interesting steve – thanks for the run-down. I’ll see if I can give graeme’s plug-in a whirl this evening (CET) when I may have some more time to think your alternatives over in detail, and to look at the discussion in the textbook again.

My initial thought is, in order to be used in practice:

It must be understandable for the user so admin area must be followable.
You need to be able to use your sorting and filtering criteria (sections and categories). If the admin cannot achieve the site how they want to, it will not be used.

I suppose for all schemes that share some fields such as sections, categories etc. you’re going to run into a problem with the url-scheme. You might be able to get around the display of section and category names using a ‘translation table’ for categories and sections (i.e. a replacement for txp:section and txp:category with a language attribute) so that depending on language it displays “Rubrikname” in place of “Section-name” when language=German…

In the past I have simply made a site with twice as many sections and categories and prefixed them with a language-prefix e.g. en-section or de-section, then adapted one of the sectionmenu plug-ins to generate a list with only one language and to strip off the language prefix in the display. I wouldn’t call it a multilingual textpattern installation, though, it’s more like a double-width site with one half masked. For the user it is straightforward, (they choose language and section together – the section drop-down is just rather long) and the url’s are language specific like the articles although they begin en- rather than en/. I think that’s the only sacrifice but even that might be spoofable with the help of mod_rewrite.

BTW: I think Bastian’s version is only for his own site, and only been in implementation since the CSS Reboot in May.

Perhaps this language discussion has outgrown this thread, and we could continue it elsewhere…

marios · 2006-06-27 07:59:15

I’ve thought about this as well, @Mary, could you port us over somewhere at the I18N section ?
I think, this is just going to disturb the rest of the auction. Users not finding their pledges, with maniqui being probably the first victim.

I’ll be off for a couple of hours and catch up on this later
@jacob, great thoughts,

regards, marios

Mary · 2006-06-27 08:11:45

I’m afraid PunBB won’t allow me to do that. I can only move entire threads, I can’t split threads/move individual posts.

net-carver · 2006-06-27 08:16:59

Mary

how about just creating the thread and then the individual authors paste their existing posts into new posts there and then delete from this thread? Might get a bit muddled up with the ordering though :(

marios · 2006-06-27 20:34:21

@steve, that’s a really nice summary of all the material. I’ll probably print this out together with all the other resources and put them in a file so I can rethink and read all that things over the weekend and make some notes.
(And set up the testing install)

regards, marios

Textpattern CMS

Textpattern CMS support forum

#85 2006-06-26 08:04:53

Re: Plugin Requests

#86 2006-06-26 20:48:27

Re: Plugin Requests

#87 2006-06-26 22:33:09

Re: Plugin Requests

One possible use: random product reviews.

#88 2006-06-26 23:34:16

Re: Plugin Requests

#89 2006-06-27 04:20:49

Re: Plugin Requests

Scheme 1: Use “Parallel” TXP-articles.

Scheme 2: Master TXP-article with a custom store for translations.

Scheme 3: Packed TXP-article + new tags.

Why I chose to explore Scheme 3.

#90 2006-06-27 05:24:19

Re: Plugin Requests

#91 2006-06-27 07:24:28

Re: Plugin Requests

#92 2006-06-27 07:25:44

Re: Plugin Requests

#93 2006-06-27 07:59:15

Re: Plugin Requests

#94 2006-06-27 08:11:45

Re: Plugin Requests

#95 2006-06-27 08:16:59

Re: Plugin Requests

#96 2006-06-27 20:34:21

Re: Plugin Requests

Board footer