Serendipity Forums

I remember reading things here about this plugin, and now I can't find them.

I thought this issue was fixed, please is this right?

I post an article in English
I add a French entry to this article

I thought when the users visit the site and they change the language, both the interface texts AND the article version were in that language. Is there any way to do this?

Also, the mention of "default" is needlessly confusing for a visitor - what do they know of 'default'? Isn't it possible to show the available languages of a post as in English, Frrench or even better English, Français?

thx in advance

When you are logged in to your s9y blog, the preferences of your user will always take precendence about the selected interface language - so try to do the same as a non-logged in user, this should then work as expected?

I think this "default" setting has been changed in recent versions of the plugin - which s9y and which plugin version are you using? What is your URL?

Regards,
Garvin

garvinhicking wrote:When you are logged in to your s9y blog, the preferences of your user will always take precendence about the selected interface language - so try to do the same as a non-logged in user, this should then work as expected?

I think this "default" setting has been changed in recent versions of the plugin - which s9y and which plugin version are you using? What is your URL?

Regards,
Garvin

Hi Garvin, I am not logged in, I look on a different PC at the blog. I was sure this worked right before and we're two days from going live!

Plugin is 1.4
S9y is 0.8.2

Ok, I wasn't able to log in before, now I'm in and can subscribe to the thread.

I know the current system of entering and editing multilingual entries is a little cumbersome and that when you are logged in to admin, you can't change languages when viewing the blog. This is not a problem.

But am I right in saying:

With language detection enabled, the Danish user goes to the blog, her browser is set to Danish and so she will see the interface in Danish AND any articles available in Danish will be show in that language?

If a Inuit speaker goes to the blog, he will fall on the defalut language version but can see everything in French by selecting that language from the selector. In that case, he will see the page in French but shouldn't the articles available in French be shown in that language?

thx

Randulo, what you are saying is right. This is how it's supposed to work. If it doesn't work that way, it's a bug. And I'd like to see the actual URL of that non-working page so I can try it.

Please also make sure you are using the most recent versions of the involved plugin(s).

Regards,
Garvin

Ok, this is nuts.

I was looking at the source (but touched nothing). I looked at the db tables (but changed nothing). I went in and deleted the original article and reposted it in two languages. For a while it didn't work right. Now it works as I expected it to do, as described above! Maybe this is a cache (ISP or s9y?) issue or something?

Now my only problem is replacing the text 'default' with the actual language name. I discovered too that the text displayed in the entry and the one in the button in admin 'choose language' are the same. It would have been better to have two separate texts because I replaced it with 'View this article in' which looks nice on the blog but weird on the admin part. I can live with that (or I could probably change it myself, it doesn't look too hard).

thanks again for the help

The 'default' problem isn't easy to get around.

The thing is, the blog has a 'default' entry which it works with, which is
automatically assumed to be in the language that the blog author has set
his/her defaults to. So if I set my working language to English the default
entry is assumed to be in English as well. The problem is, if the user later
changes the default language to something else, the previous entries won't
'stay' assigned as English entries, but just follow the new settings.

Meanwhile, the 'non-default' language entries that are tied to the default
entry have the information of what language it's written in. So it'll show
the correct name in 'Choose Language' thingy.

The problem previously mentioned becomes aggravated when the author
wants to change the default language to one of these 'non-default' ones.
The 'default' entry takes precedent, and the entries previously written in
that language is no longer accessible (well, it's still in the database, but
the reader can't see it).

Confused? Well, what I'm saying is that because s9y's multilingual support
is an extension BEHIND the existing 'default entry' framework, it's looking
like this at the moment.

Because I also maintain a multilingual blog, I've put efforts into the plugin
as well and made some other plugins to complement it (pretty evident in
my blog, I think). The 'default' problem is pretty sad to see, myself.

Now, this problem has been discussed in another thread at one point and
someone was supposed to have come up with a fix for this, but that person
hasn't been heard since...

Basically, what he proposed was to have s9y duplicate the default entry
to the multilingual table. For example, if the default language is set to
English, as soon as the author submits the entry, the contents would be
copied to under 'English' section of the multilingual table. Obviously, this
would take predence over the default entry and it would all work out,
sort of. Since even the 'default language' is pulled out from the multilingual
entries it would have the right name displayed instead of 'default'.

Here's an interesting thing, though. Then what use would the default
entry be? While the multilingual plugin that works as described is in
operation, it would be invisible. You'll be able to edit it in the admin
interface, but the changes would not show up because you would need
to edit the actual language version (which was initially copied from the
'default'), not the 'default', in order for the changes to be shown. But
if you delete the multilingual plugin, suddenly just the 'default' ones will
be visible. Hehe.

So... although basically we'd end up with duplicate data, we can't simply
empty the default entry once it's been copied to the multilingual table.
Or maybe we could.. it might be set as an option. Now, the other thing is,
should we decide to keep default entry, would it be better to have it
editable all by itself, or the changes to the multilingual entry of the
language currently specified as the default language automatically copied
to the default one (basically, the reverse of the initial input)? This has an
interesting consequence if the author decides to change the default
language somewhere along the way. The ones edited after the change
would get the version from another language than the default language
was originally written in.

So, uh, what do you think?

Well, first of all, s9y was the ONLY decent free software that worked decently with multilingual entries so I chose it almost on that basis alone!

I have messed around with changing the banners etc and have come up with a decent solution for now.

You hit the nail on the head though about 'default' and authors. I enetered stuff with default EN and everyone else is using French. They can't see my French entries to edit them because they only have 'Default and 'English' plus the other langs.

I think when I deleted and redid the articles with default as French, something happened in a cache somewhere that screwed things up for a while but they are working as expected now.

I was using a CSS technique to change the banner graphic with the kubrik plugin but that didn't work with MSIE caching so I've changed it to just use the banner image, not a CSS background. The only problem with that is to have all the graphics for all languages.

My last challenge is still to change the display for each entry from "German, French, Default" to 'Germa, French, English"

randulo wrote:My last challenge is still to change the display for each entry from "German, French, Default" to 'Germa, French, English"

Same here, actually.

The funny thing is, I would've needed multilingual blogging support but
didn't consider about it when I was searching out for a blogging system.
Somehow I landed on s9y (well, Google says it's the best php blogging
software... hmm) and after installing that did I realize I needed multi-
lingual support, and, well, there was the plugin... and the rest is history.

Now, the whole premise I described in the previous post for making that
challenge come true is probably technically possible. The problem is
to make it as least confusing as possible.

I'll be back in a moment to edit this with what was done.

Modifications to serendipity_event_multilingual.php
First I added this new text to allow you to put 'this article is available in:' and still have 'choose language' for the selector:
then I changed serendipity_config.inc.php:
To find the exact spelling of the languages, I went to HP.com they have a lot of international sites and the language is written right in the selector. You go to Denmark (Danish) for example and then look at the selector and it will say (Dansk) after the country name.

Next, I changed the display in each entry to be a list of available languages separated by spaces, not commas and the last in the list is not DEFAULT but a hard-coded 'Français'
in function &getLang($id, &$properties)
Mixing Asian and occidental languages is tough, though. I don't think it's possible to do the same thing in Japanese unless the entire installation is using UTF-8 characters.

Well, that's the thing. Unless s9y's scripts are running under the assumption
of UTF-8 encoding by default, it's going to cause problems. I think that's
why serendipity_config.inc.php had all the language names in English
instead of the native equivalent. Although s9y 0.9 will go with UTF-8 by
default, the fallback is still ISO-8859-1, I think, and so the core script such
as serendipity_config.inc.php probably won't be encoded in UTF-8... So
I guess the code changes you made will probably stay with you. Same
with the hardcoding thing.

Personally, I'd like to see a universal solution, and I think this is how it may
be done:

1. One the initial article save, multilingual plugin automatically checks the
author's default language setting and copies the contents to the multilingual
data table.

In other words, the data is now in the basic s9y entry table, as well as
under 'en' (I will assume English is default here) in multilingual entry data.

2. On the blog display, the multilingual data takes predence over the
'default' language setting. The 'default' language is shown only if the
viewer selects the language that is not covered by the multilingual data.
However, in no situation it'll list 'default' in the language selection - it
should know the author's default language, so the text should be replaced
with the appropriate one (e.g. English), even if there's no data in the
'en' part of the multilingual table. This is for backwards compatibility.

3. On subsequent editing, I have two suggestons:

a) both the 'default' and 'English' will be separately editable. As of now if
your default language is English, you can't edit the 'en' part of the
multilingual entry, but instead just given 'default' to edit. Since now the
'en' has data copied from step 1, it should be available for editing on its
own, I'm saying. Obviously, by default the listbox should select English,
not 'default', for the language. When you edit the English entry, the
changes could be applied to 'default' as well. Same with vice-versa. User
may be given an option on how this behaviour will work.

b) 'default' will be hidden, and only the multilingual data can be edited.
When you make changes to the default language, then that data will be
copied to the 'default' automatically. Think of it as the reverse of what
happened in step 1. I think this will be much less confusing than the
suggestion 'a'.

I think, from the viewer's side of view, #2 should be enough. #1 and #3
are for the author.

By the way, I'm committing a change in the plugin so that it'll show the
name of the default language in the place of 'Default' in 'Select language:'
part. Man, that was easy to fix...

This should lessen the confusion by the normal readers of the blog.

Now, as for the authors, the admin interface will still show 'Default' for the
time being.

wesley wrote:Although s9y 0.9 will go with UTF-8 by
default, the fallback is still ISO-8859-1, I think, and so the core script such
as serendipity_config.inc.php probably won't be encoded in UTF-8... So
I guess the code changes you made will probably stay with you. Same
with the hardcoding thing.

Yes, I installed .9 and it works beautifully. The problem is, we're on the eve of opening the site (it keeps getting postponed for other reasons) for an important client and I'm afraid to try to upgrade, otherwise I do now have Japanese mixed with French and it all displays right

I'll have to look in to your changes, right now I've hard-coded it but that's ok since the default language won't change on this particular site.