MLP - The Multi-Lingual Publishing Pack

marios · 2007-03-23 21:00:28

Bloke wrote:

so people not caring about my plight ought to skip this post.

I wouldn’t say so. Your medical reports are the most accurate, that have been seen on this thread so far.
The first one which include the relevant response headers.

1) Does L10n use session cookies?

I haven’t seen yet any beeing set at least, but the MLP Cleanupwizard has a delete Cookies routine. AFAIK the PHPSESSID didn’t exist in earlier 4.0x versionsof TXP.

As part of this I occasionally, randomly re-issue a brand new session token to the browser and store it in the database against their name. I know, probably overkill, but when there’s thousands of pounds of prize money at stake each week, well, who knows…

It seems, that you are well versed in Session-handling

1) Does that sound feasible/likely/possible?

I partly ( a little bit ) understood, what you are trying to say.

2) Should I not be (ab)using TXP like this?

I wouldn’t be able to answer this question. ( I’ve equiped myself, with some books and resources, to learn a little more about Session handling, AJAX, and the security aspects involved, however I haven’t had a chance yet to learn anything , but I think it’s a must know, for the tomorrow’s web )

5) Why does it only affect Firefox?!

Yes, that’s very strange indeed. BTW I just received a Sofware Update Notification from mozilla ( I’m an a mac ).

6) Is there anything I can send anyone (probably offline, I’m cluttering up posts all over the place here) to help run this down?

May be you could just zip it up , send it straight to Steve, und see if he can repruduce it at some point, I would probably have my fingers crossed , with my tiny skillset at these Issues.

regards, marios

Last edited by marios (2007-03-23 21:17:02)

Bloke · 2007-03-24 08:36:39

marios wrote:

It seems, that you are well versed in Session-handling

I wish! It’s just code borrowed off the web or from various journal articles or forums (is the plural ‘fori’?!) on the matter, tweaked to my situation. Session handling is still a little bit voodoo to me: I’m following what I think I understand to be best practice in the usual security/convenience trade-off.

May be you could just zip it up , send it straight to Steve, und see if he can repruduce it at some point

Hehehe, I doubt he’d enjoy that; he’s got enough on his plate without me throwing that at him!

I just don’t get this. I’m now at home on FF 2.0.0.3 (same version as at work yesterday) and there’s no problem with the TXP admin interface, and the PHPSESSID is not changing. If I delete the cookie, it comes back as soon as I change TXP tab but then stays fixed at the same value no matter how long I use the admin interface.

I even ran the game website itself in the same instance of FF and every few clicks I checked the user database table. The token was changing there but the value of PHPSESSID wasn’t. * head scratch * The only thing that’s changed since yesterday is the computer I’m using, my physical location in the universe and the passage of time; maybe I should ask professor Stephen Hawking for help :-)

Digging further, I checked my session.php code to make sure of my logic. I’m not even using PHPSESSID directly, opting to use my own session cookies labelled “token” and “token_time” instead:

function generateToken() {
	return md5(uniqid(rand(), TRUE));
}
function createTokenPair($name) {
	$newtoken = generateToken();
	$theTime = time();
	$ret = setToken($name, $newtoken, $theTime);
	$_SESSION['token'] = $newtoken;
	$_SESSION['token_time'] = $theTime;
//echo " GENERATED NEW TOKEN: ".$newtoken . " AT ".$_SESSION['token_time'];
}

setToken() is a simple db call that updates the given user record to set the new token. The browser must take care of keeping the user session logged in (if I delete the PHPSESSID, my user logged into the game website gets kicked out) but at no time are the PHPSESSID and my token the same. That kind of explains the static nature of PHPSESSID but doesn’t explain why Firefox was hanging yesterday and deleting PHPSESSID or disabling L10n fixed it, when today at home it’s fine. Maybe it is the browser installation environment after all, although it’s done the hanging behaviour at home before.

I really am stumped. Perhaps I’ll just bury my head in the sand and not hijack this thread any longer. Sorry for all this.

marios · 2007-03-24 19:17:05

I think, I found an Issue, wenn using TXP Language update:

Wenn updating a language file, from the admin prefs panel, then the MLP Pack, will display again all Snippets as unrendered for that specific language, allthough everything is still there. the l10lang strings appear to have been removed, under MLP plugins and the statstics go down.
The lang also then disappears under MLP/plugins statistics, while under MLP/smippets, the lang is still there.

The thing now, is I’ve lost all the en-gb renditions, that are supposed to show up under MLP/Plugins, how can I get those back now ?
I’m really confused at the moment. ( I didn’t keep a backup )

Could someone send me the base 64-encoded en-gb default renditions ?

However, this is what I think:

To prevent Powerusers ( That’s mainly the Idiot, that I am myself ) from mistakenly remove the default renditions through updating a lang file in the usual way, the file should be protected in some way, of may be the renditions entirely separated, from the lang files in the lang directory)

I could unfortunately also not get the update from file feature not getting to work, with that rv of TXP.

@bloke, fingers crossed.

regards, marios

Last edited by marios (2007-03-24 20:44:47)

marios · 2007-03-24 21:38:16

Export Feature of the default l10lang strings is still giving the file as an array in a php file format ( not encoded), so there is no way to reimport it back.
Supposedly the following isn’t implemented yet, but I’ll just add it to the list.

The mlp Pack and Textpattern base inst lang export options should have a new string variable which says:

Select the lang, you wish to export from the drop-down select, and then click the Export button ,

instead of:

Select languages you wish to include and then click the button. ,

which is used for the export snippet strings function. There is a screenshot below:

regards, marios

advis · 2007-03-25 09:29:54

I’ve just try MLP for very first time. And the first thing i hung up to use it was the error knowing as “blank page” or “blank write”. Will be happy if you get to solve it. For now I can not to use MLP at all, because my host is run PHP 5 on it and I can not to change this. I attach my diagnostic info if it help. Hope the fix will coming soon.
“And thanks for all of your work people” Maybe I can to translate MLP to Slovak language, if will able to use it. Good luck and excuse my English.
————————————
Textpattern version: 4.0.4 (r1956)
Last Update: 2007-03-21 16:18:23/2007-03-21 15:54:18

PHP version: 5.0.5
Server Local Time: 2007-03-25 11:01:56
MySQL: 4.1.14
Locale: en_GB.UTF-8
Server: Apache
Apache version: Apache
PHP Server API: apache2handler
RFC 2616 headers:
Server OS: Linux 2.6.11-gentoo-r6

Pre-flight check:
————————————
The following PHP functions (which may be necessary to run Textpattern) are disabled on your server: exec, system, pXhXpXiXnXfo, passthru, proc_close, proc_get_status, proc_nice, proc_open, proc_terminate,shell_exec,popen,dl
————————————

advis · 2007-03-25 09:34:59

Forgot to say, I had to install it in subdirectory.

net-carver · 2007-03-25 19:56:25

advis

Subdirectory installs have known problems. Still a work-in-progress.

Marios wrote:

Export Feature of the default l10lang strings is still giving the file as an array in a php file format ( not encoded), so there is no way to reimport it back.

That’s the correct behaviour.

That option is to allow the creation of MLP distributions with non-English (or previously un-translated) languages available from the word go. For example, if you were to translate the MLP pack into something like Greek then use that export option you get a php file you can include in your own MLP zip package for redistribution. Now when you install from that zip onto a shiney, new TxP install setup for Greek on a client’s new site, then you are immediately greeted with the Greek strings and can install with Greek set as your default language.

At least, that was the idea behind it.

net-carver · 2007-03-25 20:09:53

Bloke

Yes, the MLP pack uses session cookies to track the visitor’s browse language.

“A visitor accessing your web site is assigned a unique id, the so-called session id. This is either stored in a cookie on the user side or is propagated in the URL.” – The PHP manual.

So, the PHPSESSIONID cookie on your browser is simply an ID, that doesn’t change across accesses by the user for this session. So you shouldn’t worry about why it isn’t changing — it won’t!

What is changing is the data stored vs that session id on the server.

ultramega · 2007-03-26 07:14:03

ultramega wrote:

Fatal error: Call to undefined function: retitle_article() in /www/customers/mydomain/public_html/textpattern/lib/l10n_admin.php on line 680

showed bottom of the admin-page after updating article.

net-carver wrote:

Ok, this just might be a problem with your l10n_admin_classes.php file.

And so it was, changing to new one fixed it. Thanks :)

When you publish new versions of this plugin, are there files we we should keep when we have modified translations? Or does all translations exist in database, and installation-files can be safely be overwritten via ftp? Maybe stupid question, but this is not quite clear for me…

guiguibonbon · 2007-03-26 12:04:18

Hi Steve, thanks for the mails, glad you’re back (don’t put too much pressure on yourself though, family goes first).

I think what’s happening with the author pages (and also happens with the category pages when no section is specified : www.mysite.com/category/mycategory) is that the translated url only adds the language mark, but doesn’t translate the “category” and “author” words in the url into the correct language, which causes the 404.

Also, am I missing something, or is the site’s name not translatable (as the slogan is)? That would be a nice feature.

net-carver · 2007-03-26 13:12:54

ultramega wrote:

When you publish new versions of this plugin, are there files we we should keep when we have modified translations? Or does all translations exist in database, and installation-files can be safely be overwritten via ftp?

Your content (forms/pages/articles/snippets) are all stored in the DB. So unless you have modified some of the language files or the big code->language name mappings in the l10n_langs.php file then you can safely update the entire installation from the zip each time.

If you don’t like the default code -> language mappings and have modified the strings (for example, ‘en-gb’ maps to ‘English (GB)’ by default but some people prefer the simpler ‘English’ and have therefore modified the mappings) then you’ll need to retain that file over the update to keep your changes.

Each time I post a new ZIP it is not an incremental patch on the previous one, it is released as a full installation archive. You’d need to do a diff on the file contents between two zips to see which files have been updated.

Hope that helps.

guiguibonbon wrote:

I think what’s happening with the author pages (and also happens with the category pages when no section is specified : www.mysite.com/category/mycategory) is that the translated url only adds the language mark, but doesn’t translate the “category” and “author” words in the url into the correct language, which causes the 404.

Hum, maybe I’m having a senior moment but I thought that author/category names in URLs were not meant to be translated but to remain fixed based on the content of the ‘Article category name’ field on the content > categories > (category name) page.

However, you are right about a 404 error on the page — looks like it’s a missing ‘/’ before the ?c=blah-blah-blah portion of the URL. Could you try inserting it manually and see if that works for you.

Also, am I missing something, or is the site’s name not translatable (as the slogan is)? That would be a nice feature.

You’re not missing anything. The site title isn’t localisable at the moment. Can add that as a feature request.

guiguibonbon · 2007-03-26 13:49:19

net-carver wrote:

Hum, maybe I’m having a senior moment but I thought that author/category names in URLs were not meant to be translated but to remain fixed based on the content of the ‘Article category name’ field on the content > categories > (category name) page.

What i meant is this, when you put a category_list tag without specifying a section, it outputs links that look like : www.mysite.com/category/aaa in English, and www.mysite.com/categorie/aaa in French; for instance. Likewise, I believe author pages are www.mysite.com/author/name in English and www.mysite.com/auteur/name in French. When being on one of those pages l10n_lang_list outputs www.mysite.com/fr/category/aaa if i was in English, while that should have been www.mysite.com/fr/categorie/aaa

see what i mean?

Last edited by guiguibonbon (2007-03-26 13:51:59)

Textpattern CMS

Textpattern CMS support forum

#181 2007-03-23 21:00:28

Re: MLP - The Multi-Lingual Publishing Pack

#182 2007-03-24 08:36:39

Re: MLP - The Multi-Lingual Publishing Pack

#183 2007-03-24 19:17:05

Re: MLP - The Multi-Lingual Publishing Pack

Could someone send me the base 64-encoded en-gb default renditions ?

#184 2007-03-24 21:38:16

Re: MLP - The Multi-Lingual Publishing Pack

#185 2007-03-25 09:29:54

Re: MLP - The Multi-Lingual Publishing Pack

#186 2007-03-25 09:34:59

Re: MLP - The Multi-Lingual Publishing Pack

#187 2007-03-25 19:56:25

Re: MLP - The Multi-Lingual Publishing Pack

#188 2007-03-25 20:09:53

Re: MLP - The Multi-Lingual Publishing Pack

#189 2007-03-26 07:14:03

Re: MLP - The Multi-Lingual Publishing Pack

#190 2007-03-26 12:04:18

Re: MLP - The Multi-Lingual Publishing Pack

#191 2007-03-26 13:12:54

Re: MLP - The Multi-Lingual Publishing Pack

#192 2007-03-26 13:49:19

Re: MLP - The Multi-Lingual Publishing Pack

Board footer