Serendipity Forums

I was attracted to s9y because of its multilingual plugin. Once I tried s9y, I really liked though. The more I've used it the more I like it as a CMS and I've been using it embedded on several sites for news pages etc. However...

There are a couple of things I'd really like see and they all involve article properties.

I have written a few news page CMS myself and they all were bilingual. The language was just another column in the articles (or entries) table. I wonder why this wasn't done in s9y in the first place? The multilingual plugin was a great gift, but it really has disadvantages as we all know. I can't fix s9y because I can't take the time to understand it intimately enough to modify its core and even if I did, I doubt anyone would want to integrate my stuff, so it'd be a waste of time.

If I had a prayer, it would be to add native language support plus:
- start date and end date for auto publishing so you can write a draft and auto-publish between two dates
- an option for the reader to choose the languages of article to read, in other words, if only some are in French and I only read French, show me only those.

Naturally, the plugins would have to respect this logic so it's a non-trivial request, but that's what I'd like to see happen.

With regard to say, static pages and HTML language specific sidebar stuff, it's easy enough to have different versions for each language, but for the basic s9y entities, it's tiresome to be tied to the same date and extra variables of the default language. When I've had to, I've installed s9y to two different locations using two databases but sharing some of the directories via symlinks. That's the best I could come up with.

Please hear me Ô lords of the programming world.

Well, creating another column in the _x table (body_english, body_ ...) would be a real waste, as adding a new language would also mean adding a new column.

In fact the way the multilingual entry plugin handles plugin is the best normalized way, thus the best way to add independent columns in a relational database. Any other option would actually make less sense.

About your other requests:

* Autopublishing could be solved with a Custom Entry property field. Using the extended properties of entries plugin you can add a column "enddate". Then you can edit your entries.tpl template and just skip all entries whose $entry.ep_enddate is smaller than the current timestamp. Adding it into a plugin would also be not so hard, but require some SQL skills. It would be avery nice task for someone wanting to get his hands into the serendipity plugin API!

The same goes with the toggle of only articles in a specific language. It's just a small change in the SQL, also a good task for a newbie in our Plugin API.

So, who wants to have a go at these things?

About your last thing: Why is there a problem sharing the same entry date and things for the same entry? Why would you want to have different dates for a language for the same entry? Wouldn't then two independent entries make more sense?

In the end, of course I agree with you. The multilingual plugin could be enhanced a bit. Since I personally don't use the plugin and I think in its current state it is quite usable, I have little time and motivation to improve it myself. So I hope someone strays along who'd like to get his hands all dirty with Serendipity Plugin Coding. )

Best regards,
Garvin

Garvin,

All the points you make are good ones, of course, especially about the ease of adding relatively small extensions to the tpl. I wish I had more time to look at doing this kind of thing. Hmmm, this reminds me that I thought about looking at some Smarty docs RealSoonNow

Well, creating another column in the _x table (body_english, body_ ...) would be a real waste, as adding a new language would also mean adding a new column.

Actually, what I meant was creating one column in entries 'language' enum (en|fr|de, etc). Yes, articles would appear once for each language but I don't think that's such a big deal. The biggest field is the text anyway, is it not?

I think one of the biggest problems with the plugin approach really has to do with other plugins not caring about the language. In that case (staticpages, for example) we do have two different entries for each section. Unfortunately, the navigation part of static pages is indifferent to the language. The way language depends on one plugin and needing to modify a lot of other ones makes it hard to want to update s9y when the time comes, for fear of messing something up. Still, I suppose if we stay at a stable version, we could make as many changes as we like, eh?

About the why different publish dates, let me put it another way: the language entries are too closely coupled IMO, so you can't put "language 2" before entering the default, as we all know. Also, can you publish the entry in one language and leave the others in draft?

Also, what about searches or the fancy archivecontents plugin?
Of course, multilingual blogs are not for everyone, in fact they're probably not that common. As you know, I like s9y a lot and use it for many things, not just blogs.

I guess the prayer should be directed at plugin creators!

Hi!

Actually, what I meant was creating one column in entries 'language' enum (en|fr|de, etc). Yes, articles would appear once for each language but I don't think that's such a big deal. The biggest field is the text anyway, is it not?

It would screw up the whole entry handling, because the entry id is the autoincrement field, and this would mean having multiple entries for only one entry. This would serously screw up the whole logic for many plugins and a full backwards compatibility break.

The way how it is added into the entry_prooerties table is really the best approach, please trust me in this. It has the least overhead, and from a relational database point of view is the best solution to this normalizing problem.

Your point about plugin approach with other plugins not caring about the language: If we had a new entry ID, each and every plugin dealing with entries would have to be modified! And if you take that step, you could already modify every plugin to be aware of the entryproperties field instead. This would be really the sanest thing to do.

So we should sit down and think about which plugins do not properly deal with language versions and patch them up. I for only currently do not even know about such plugins that are making problems with multilingual entries.

The only think I know of would be the quicksearch not searching multilingual entries or static pages. This is an easy task for a developer to patch, so I'm leaving this task for any new programmer that wants to join Serendipity and have a go at something.

About the why different publish dates, let me put it another way: the language entries are too closely coupled IMO, so you can't put "language 2" before entering the default, as we all know. Also, can you publish the entry in one language and leave the others in draft?

You could store different publish/draft states in the entryproperties table as well; and IMHO you could also leave the default language entry blank when creating an different language version of an article. I agree, it would be a nice think to have different draft/publish states for multilingual entries.

I really hope that some developer comes along who wants to enhance the current possibilities. I'll be all hands on helping those people, so if there are question, please let me know. But my current time schedule allows me no time to work in this area, as there are currently other pressing matters for me to finish. :-/

Best regards,
Garvin