MLP - The Multi-Lingual Publishing Pack

els · 2008-12-02 20:14:54

maartenD wrote:

Second questions, is there a way to change these tables to utf8_general_ci?

Use rvm_latin1_to_utf8. I’ve been using it on all my older databases, it’s a piece of cake!

I’ll let Steve answer your other questions, but I realize that I shouldn’t have said that MLP works in 4.0.7: I’m running sort of a guinea pig version ;) so you’d better wait until Steve has updated the pack.

maartenD · 2008-12-02 20:18:14

Hello Els,

Tnx for the quick reply. I will take a look at the plug-in you mentioned and wait till Steve posted that the plug-in is ready for 4.0.7.

Kind regards,

Maarten.

the_ghost · 2008-12-04 23:48:18

Bug found when used undocumented feature after this help of Steve:

1. When i use l10n_lang_list tag like this <txp:l10n_lang_list show_empty="1" article_list="any_string"/> (i want to see link for english article even if english rendition is absent) i get this html output:

<ul class="l10n_lang_list"><li class="ru-ru"><a href="http://rusx.org/ru/index.php?id=202"><span dir="ltr"><strong>Русский</strong> : Телефон прямой связи Мэрии Москвы с жителями города</span></a></li>
	<li>English</li></ul>

Thie bug is that inside of link to existing russian rendition the Title of this article was inserted by some magic :)

I have this –
It should be like this

2. And another trouble with using non-zero value in attr article_list is that if english rendition exists and we are viewing russian rendition, the link is building to russian rendition, instead of english rendition (current URL is http://site.org/ru/index.php?id=46). Here is the html code:

<ul class="l10n_lang_list"><li class="ru-ru l10n_current"><span dir="ltr">Русский</span></li>
	<li class="en-us"><a href="http://rusx.org/en/index.php?id=206"><span dir="ltr">English</span></a></li></ul>

3. Bug with deleting articles

I create new article, so the article and it’s russian rendition are created at the moment i save.
At list (http://site.org/textpattern/index.php?event=list) i check just created article and delete it. It disappears from admin-side, but it still appears in mysql db and can appear at site, if txp:article or txp:article_custom match its params! I manually delete this article from db by editing l10n_txp_ru_ru table.
if insted of step #2 i use MLP tab (http://site.org/textpattern/index.php?event=l10n) and delete article (not russian rendition – the whole article) – everything is “ok”…

Last edited by the_ghost (2008-12-05 01:19:48)

net-carver · 2008-12-07 23:35:02

All

Further to my previous snapshot promise, I hope the latest snapshot fixes the 4.0.7 compatibility problems reported by folks.

This one has these fixes…

compatibility with version 4.0.7 of txp (columns, indexes, admin language switcher insertion into header and footer & insertion of tags into example pages in new installations.)
compatibility with the 4.0.7 changes to txplib_db.php
a bug in my SQL that Els and the_ghost found (probably others too.)
Els’ string editing bug
Els’ double line spacing problem with exported stringsets.

Improves…

Admin side localisation of category/section names (but this is still incomplete)
version numbering: updated to v0.9.x to avoid problems with confusing 0.8.x series version numbers.

And adds…

new tag: l10n_get_rendition_id
new indexes to the articles’ language & group columns in the DB
an l10n ‘dirty’ flag entry to the admin > prefs > basic page to allow rebuilds of the per-language tables. (Just enter ‘DIRTY’ — in caps, without the quotes — and save the page, then visit any admin page to force a rebuild). Interface for this will probably change in the next snapshot.
(by popular request) l10n_langs.php changes to the entries for both British and American English — they are both now ‘English’ instead of ‘English (GB)’ and ‘English (US)’ respectively.

I know you’ll let me know how it goes.

beztak · 2008-12-08 08:54:57

Thank you, works fine for me on two new 4.0.7 sites… (but I didn’t notice any problem with 4.0.7 before your plugin update).

maniqui · 2008-12-09 23:37:07

hi net-carver,
thanks for this new release. I’ve upgraded it on a Txp 4.0.7 and so far, it seems to work flawlessly.
One question about the upgrade: does the install/uninstall wizard need to be run? I ask because in the previous release (0.9.9dev, the one released but then removed from public download), Els suggested me to do so (run the uninstall wizard and then the install wizard).
I suppose that, if everything seems to be working, there’s no need to run wizards. Or does running the wizard do some extra white magic, particularly on the database (and related to the “new indexes” mentioned on your list of additions?

net-carver wrote:

Improves…

Admin side localisation of category/section names (but this is still incomplete)

Being just admin side, I suppose this is not related with 009, our KIA double zero agent. Maybe 009 isn’t KIA but just MIA and there is still a hope ;)

And adds…

new tag: l10n_get_rendition_id

Oh, it’s not documented in the help yet. Care to explain what it does? Is it the same as txp:article_id?

BTW, l10n_rendition_lang, shouldn’t it be l10n_get_rendition_lang, for consistency?

an l10n ‘dirty’ flag entry to the admin > prefs > basic page to allow rebuilds of the per-language tables. (Just enter ‘DIRTY’ — in caps, without the quotes — and save the page, then visit any admin page to force a rebuild). Interface for this will probably change in the next snapshot.

What does this dirty thing do?

azw · 2008-12-09 23:46:28

Or maybe the tags could be simplified to:
l10n_rendition_id (removing “get”)
l10n_rendition_lang (which is what it is now)
Fewer characters = fewer mistakes!

net-carver · 2008-12-10 22:38:45

maniqui wrote:

hi net-carver,
thanks for this new release. I’ve upgraded it on a Txp 4.0.7 and so far, it seems to work flawlessly.

Julián
glad it’s working for you.

One question about the upgrade: does the install/uninstall wizard need to be run? … <snip> … Els suggested me to do so (run the uninstall wizard and then the install wizard). … <snip> … What does this dirty thing do?

Els advice was right for 0.9.9dev (now withdrawn) but unnecessary for 0.9.10dev.

This version changes the way the per-language tables are created and filled up with rows from the master textpattern table. The per-lang tables will now automatically get rebuilt whenever textpattern itself is upgraded or if you run the SVN copy. Hopefully this will keep the tables in lock-step with additional columns and indexes (indices) intoduced via txp core. Previously the per-language tables were only built when the install wizard was run.

The ‘Dirty’ flag is used to take care of changes to the master textpattern table’s structure that might be made by plugins. Currently MLP only tracks changes made by Gerhard’s glz_custom_field plugin. When it makes a change, the MLP Pack sets the flag and on the next admin event, the per-language tables are re-built to reflect the structure+data changes that the plugin is made.

Should you ever find you get SQL warnings about missing columns for plugins that modified the structure of the textpattern table and are now expecting the columns, you can trigger a manual rebuild of the per-language tables yourself by entering ‘DIRTY’ into the pref, saving the page and then reloading. This interface for manual rebuild will probably change next release — it’s too crude. I may play with totally automating detection of differences between the master and per-language tables. If that works there may be no need to provide an interface for this at all.

net-carver wrote:
Improves…

Admin side localisation of category/section names (but this is still incomplete)

Being just admin side, I suppose this is not related with 009, our KIA double zero agent. Maybe 009 isn’t KIA but just MIA and there is still a hope ;)

Actually, this is to do with display of category titles in pages like the images / file edit tabs.

And adds…

new tag: l10n_get_rendition_id

Oh, it’s not documented in the help yet. Care to explain what it does? Is it the same as txp:article_id?

Oops. Thanks, I’ll fix that.

maniqui wrote:

BTW, l10n_rendition_lang, shouldn’t it be l10n_get_rendition_lang, for consistency?

…and azw wrote: …

Or maybe the tags could be simplified to:
l10n_rendition_id (removing “get”)
l10n_rendition_lang (which is what it is now)
Fewer characters = fewer mistakes!

Thanks guys, I’ll look at the naming for the next snapshot.

the_ghost · 2008-12-11 00:56:34

So, per-language renditions still are storring in separate tables? Is it a huge work to use textapttern table with additional columns, like Title_en or Body_html_en and so on.. I think such will reduce code when you have to search for rendition’s id and other to communicate between original textpattern table and tables fot languages.

Are things i wrote understandable? :) hope so…

net-carver · 2008-12-11 01:32:31

Виктор

Currently, all renditions, of whatever language and article, are in the textpattern table in native txp format. The per-language tables are used simply as a public-interface cache of renditions for each language. This is quite a simple scheme that avoids the need to add per-language columns to the table or do fun things like create temporary tables or re-write the SQL queries in the DB layer. It also avoids a lot of DB overhead if you have a lot of semi-translated articles.

I do take the approach you mention with things in some other tables — like the images and files — but not with the textpattern table.

I’ll think about it now you’ve mentioned it as there would be some advantages to dropping the need to maintain the integrity of the cache in face of plugins adding columns and indexes and core changes between releases. However, I don’t think the cache integrity problem is impossible.

Thanks for the idea!

maniqui · 2008-12-11 03:15:45

Thanks for the detailed reply and explanation, Steve.

Re: removing "_get_" from some MLP tags names. I think "_get_" makes sense on some MLP tags, when it’s related to some visitor’s browser/browsing variable.
In other words there are some tags that fetch information from the article (rendition) and some tags that fetch information from the session/context. But I may be wrong.

And now, a new crazy and/or dumb feature request -that may already be possible with current MLP tags + Txp 4.0.7 new features:

What if a rendition for an article could access fields (custom fields, article_image, etc) from another rendition of the same article?

Example: an article can have an associated image. In this example, all renditions share the same image. So, currently, you insert the image ID on every rendition in the article_image field.

But, if such a feature could be possible, then you could insert the image ID in just one rendition and then leave it empty (i.e. article_image field will be empty) in the other renditions. When rendering this other renditions, the value for that field will be the one from the rendition that has the value filled.
Of course, this arises some question like, what about if two renditions have the field filled but one rendition doesn’t. Which value (from the two renditions with that filled field ) should that rendition use?

That could be configurable using some tag attributes (mmmm, no… not sure) or better, some configurable option on the MLP > Preferences tab, maybe with two radio buttons (one of those two, associated with an text input field), like

If field is empty:

( ) do nothing <- this is current behaviour for BC)
(*) use value from: [default-lang, en, es, fr, pr] <- this is a text input field where user set some comma-separated values for priority.

Does all this make any sense?
I think (have to think a little harder) this may be possible using some current MLP tags and 4.0.7 features like tags-in-tags and variables. (/me is summoning his own death brain to think a little about this).

Another possible (real-world situation) use of this:

I was thinking how to associate an article to an image category via the article_url_title. For this, I would create an image category, and its name would match exactly the article_url_title for the default language.
I would upload some photos and assign them to that image category.
Then, using some tags in tags (for example, <txp:smd_gallery category='<txp:article_url_title />' />), I would fetch the corresponding images for a category that matches the article_url_title.
But, currently, each rendition will return its translated article_url_title.

If I could get the article ID for some (predefined) language rendition, then I could use it as the attribute of an article_custom id attribute, and using that article_custom tag as a container tag, and assign its rendered value to a txp:variable, it may be possible to achieve what I’m trying… :D

ps: this ideas came during a raggabuffer override experience. Sorry for the prose.

Last edited by maniqui (2008-12-11 04:05:24)

xbelanch · 2008-12-13 17:45:24

[[SOLVED!]]

Hi!

I have some warnings and one error :-( when I installed the three plugins and the lib content. Textpattern version: 4.0.7 (r3025) and MPL Plugin 0.9.10

A problem occured while loading the plugin: l10n -> Warning: include_once(/Users/xbelanch/Sites/blog2/textpattern/lib/l10n_base.php) [function.include-once]: failed to open stream: No such file or directory on line 325
textpattern/lib/txplib_misc.php(574) : eval()’d code:325 include_once()
textpattern/lib/txplib_misc.php:574 eval()
textpattern/index.php:101 load_plugins()
A problem occured while loading the plugin: l10n -> Warning: include_once() [function.include]: Failed opening ‘/Users/xbelanch/Sites/blog2/textpattern/lib/l10n_base.php’ for inclusion (include_path=’.:/usr/local/php5/lib/php’) on line 325
textpattern/lib/txplib_misc.php(574) : eval()’d code:325 include_once()
textpattern/lib/txplib_misc.php:574 eval()
textpattern/index.php:101 load_plugins()
A problem occured while loading the plugin: l10n -> Warning: include_once(/Users/xbelanch/Sites/blog2/textpattern/lib/l10n_admin_classes.php) [function.include-once]: failed to open stream: No such file or directory on line 357
textpattern/lib/txplib_misc.php(574) : eval()’d code:357 include_once()
textpattern/lib/txplib_misc.php:574 eval()
textpattern/index.php:101 load_plugins()
A problem occured while loading the plugin: l10n -> Warning: include_once() [function.include]: Failed opening ‘/Users/xbelanch/Sites/blog2/textpattern/lib/l10n_admin_classes.php’ for inclusion (include_path=’.:/usr/local/php5/lib/php’) on line 357
textpattern/lib/txplib_misc.php(574) : eval()’d code:357 include_once()
textpattern/lib/txplib_misc.php:574 eval()
textpattern/index.php:101 load_plugins()

Fatal error: Class ‘MLPPlugin’ not found in /Users/xbelanch/Sites/blog/textpattern/lib/txplib_misc.php(574) : eval()’d code on line 358

What’s I make the mistake :-? I follow every step of the mandatory instructions of pre and before installation…
Thanks for the help :-)

Xavier

Last edited by xbelanch (2008-12-15 12:03:30)

Textpattern CMS

Textpattern CMS support forum

#1081 2008-12-02 20:14:54

Re: MLP - The Multi-Lingual Publishing Pack

#1082 2008-12-02 20:18:14

Re: MLP - The Multi-Lingual Publishing Pack

#1083 2008-12-04 23:48:18

Re: MLP - The Multi-Lingual Publishing Pack

#1084 2008-12-07 23:35:02

Re: MLP - The Multi-Lingual Publishing Pack

#1085 2008-12-08 08:54:57

Re: MLP - The Multi-Lingual Publishing Pack

#1086 2008-12-09 23:37:07

Re: MLP - The Multi-Lingual Publishing Pack

#1087 2008-12-09 23:46:28

Re: MLP - The Multi-Lingual Publishing Pack

#1088 2008-12-10 22:38:45

Re: MLP - The Multi-Lingual Publishing Pack

#1089 2008-12-11 00:56:34

Re: MLP - The Multi-Lingual Publishing Pack

#1090 2008-12-11 01:32:31

Re: MLP - The Multi-Lingual Publishing Pack

#1091 2008-12-11 03:15:45

Re: MLP - The Multi-Lingual Publishing Pack

#1092 2008-12-13 17:45:24

Re: MLP - The Multi-Lingual Publishing Pack

Board footer