Multilingual plugin & browser's language

[krist]

I maintain a German blog and I now want to make use of the multilingual plugin to translate some articles into English. Ideally I don't want a language selection footer or drop down box in the sidebar but have the language shown accordingly to the browser's setting. I've seen this working perfectly on other S9Y-based blogs like Carl Galloway's site. However if my blog is accessed with a browser set to English only the date, plugin headlines, footer, etc. are shown in English but not the articles itself.

As an example, this article
http://mundpropaganda.org/index.php?/ar ... ernet.html
is available in German & English.

What's wrong here? Where should I start looking?

Also if I enable the drop down box in the sidebar it remains empty.

EDIT:
The drop down box works correctly if I just enable the languages which are actually available in the plugin's sidebar settings

EDIT2:
After some more testing I found out, that it's working if it's the other way around. Setting the blog's language to English, having the default entries in English and adding a German translation leads to the behaviour I want. This way the feeds would deliver English content as well which I don't want them to do. Is this overall behaviour intended? If I want to keep German as the default language, do I _have_ to work with the language selection footer and/or drop down box?

[garvinhicking]

Hi!

There are several things that influence the displayed language when using this plugin:

1. If the global s9y configuration is enabled to use the HTTP-Browser language

2. If you are logged in, your PERSONAL language is always preferred, also over any dropdown selection you have made.

3. If you used the language dropdown at some time, it stores the last language inside a cookie.

4. Also the GLOBAL language of your blog defines what your default language is. NOT the personal configured language!

I must admit the multilingual plugin is one of the most complex plugins with the highest "WTF"-Factor. So I hope my mumblings make some sense, because I'm currently not that much into this plgin

Best regards,
Garvin

[krist]

Hi Garvin,

Thanks for the reply, I've noticed most of these dependencies already. My PHP knowledge is limited but I'll try to tweak the plugin to give the browser's HTTP language setting a higher priority when deciding which language to choose for the entry's text.

[garvinhicking]

Hi!

That would be very welcome! Hope you'll be able to get through the code

Best regards,
Garvin

[krist]

I had some time today to look into the plugin's code... and to learn some more PHP as well
To get it working like I want I actually just needed to change one line:

serendipity_event_multilingual.php, line 423-425

Code: Select all

                    if (empty($this->showlang)) {
                        return;
                    }

Patched to:

Code: Select all

                    if (empty($this->showlang)) {
                        $this->showlang = $serendipity['lang'];
                    }

Works for the rss feeds, too (though most RSS readers don't seem to include the preferred language in their request headers). I don't know if it breaks anything else or only works with my personal setup, so some more testing is required.

[Fencer]

I have a problem with entering localized version of articles on my blog. I have tried to translate one entry to Czech, which worked and the link to the Czech version appeared below the article body. However, when I wanted to do the same with Turkish, the translation never appeared and it looks like it was not saved at the database.
Can it be related to the Choose Language plugin? It is another strange thing because this plugin doesn't show a Turkish option, although the article edit form offers Turkish as a language to localize to. Is there anything I missed?

Thank you.
Filip

[garvinhicking]

Hi!

I think the language chooser plugin has the names of the available languages saved in the PHP file instead of drawing the list from $serendipity['languages']. It might be that this is causing your trouble, because turkish is a quite new language to s9y...I sadly currently don't have a development machine to easily check out the dependencies...

Best regards,
Garvin

[Fencer]

Thanks fo your prompt response Garvin I'll be patient. At least I am glad the problem was not caused by me.

Filip

Hi!

I think the language chooser plugin has the names of the available languages saved in the PHP file instead of drawing the list from $serendipity['languages']. It might be that this is causing your trouble, because turkish is a quite new language to s9y...I sadly currently don't have a development machine to easily check out the dependencies...

Best regards,
Garvin

[judebert]

Version 1.8 on serendipity_plugin_multilingual (language chooser dropdown) pulls from $serendipity['languages'].

The event plugin searches for properties of the entry matching multilingual_body_{language}.

I'd look in the database and see what properties are set for the entry (in this case, ID 31). Did multilingual_body_turkish (or similar) get set?

[Fencer]

I'd look in the database and see what properties are set for the entry (in this case, ID 31). Did multilingual_body_turkish (or similar) get set?

No, it sets no properties when I try to submit the Turkish translation.

Filip

[Fencer]

Hi!

I think the language chooser plugin has the names of the available languages saved in the PHP file instead of drawing the list from $serendipity['languages']. It might be that this is causing your trouble, because turkish is a quite new language to s9y...I sadly currently don't have a development machine to easily check out the dependencies...

Best regards,
Garvin

The Turkish option was really missing at the serendipity_plugin_multilingual.php file, so I've added it and now it appears at the Choose Language combobox. However, entering a Turkish translation of an entry still does not work.

Filip

[garvinhicking]

I'll look also into this when i have my dev machine back.

Regards,
garvin

[judebert]

Are you using Serendipity v. 1.1 and language chooser event plugin v. 1.28?

It's possible you can work around the problem until we get it figured out: try saving the entry as a different language, then changing only its language to Turkish. The plugin treats these two cases slightly differently.

No, it sets no properties when I try to submit the Turkish translation.

That tells me that the backend_save hook isn't detecting that you want a save in Turkish. The code in question is:

Code: Select all

if (!isset($serendipity['POST']['properties']) || !is_array($serendipity['POST']['properties']) || !isset($eventData['id']) || empty($serendipity['POST']['properties']['lang_selected'])) {
    return true;
}

If you can add a simple "print 'No language selected!';" before the "return true;", this will tell you if it's being directly skipped.

Later, there's this code:

Code: Select all

foreach($this->supported_properties AS $prop_key) {
    $prop_val = (isset($serendipity['POST']['properties'][$prop_key]) ? $serendipity['POST']['properties'][$prop_key] : null);
    if (!isset($property[$prop_key]) && !empty($prop_val)) {
        $q = "INSERT INTO {$serendipity['dbPrefix']}entryproperties (entryid, property, value) VALUES (" . (int)$eventData['id'] . ", '" . serendipity_db_escape_string($prop_key) . "', '" . serendipity_db_escape_string($prop_val) . "')";
    } elseif ($property[$propkey] != $prop_val && !empty($prop_val)) {
        $q = "UPDATE {$serendipity['dbPrefix']}entryproperties SET value = '" . serendipity_db_escape_string($prop_val) . "' WHERE entryid = " . (int)$eventData['id'] . " AND property = '" . serendipity_db_escape_string($prop_key) . "'";
    } else {
        $q = "DELETE FROM {$serendipity['dbPrefix']}entryproperties WHERE entryid = " . (int)$eventData['id'] . " AND property = '" . serendipity_db_escape_string($prop_key) . "'";
    }

    serendipity_db_query($q);
}

Adding another print statement in each of those if/else clauses will give you further insight into the problem.

And, looking at it, I see that it's using the improper comparison $propkey, instead of $prop_key. I'd change that and try again, first.