multilingual_plugin inconsistent?

[kitten]

Hi,

Could it be that I'm the only one who encounters this problem with the multilingual plugin? I already searched the forums...

In the backend, after entering one or more translations, I re-select the "default" language, but I always see the content of the last selected language (instead of the default language content).

As far as I can see, the information is written correctly to the database.

Anyone?

Edit: I tested with 0.8.2 out of the box...

[garvinhicking]

"Reselecting" the default language will not work, as once you have used the dropdown, serendipity will think the last selected language (as you've noticed) is the default one. You need to edit the entry again to get back to that.

This is a conceptual flaw that I have not yet gotten around looking into, as I myself don't use the plugin and focussed on other things.

Regards,
Garvin

[kitten]

Thank you, Garvin!

I would really like to rewrite it -- what a pity that I am not familiar enough (yet) with the serendipity code

[garvinhicking]

I'm really sorry. Maybe once you're familiar with the code...

I'd love to help you if you have any questions, problems or whatever. We need people get involved with our code to further improve Serendipity.

Regards,
Garvin

[kitten]

In serendipity_event_multilingual.php, the case "backend_entryform" now looks like this:

Code: Select all

				case 'backend_entryform':
					if (!empty($this->showlang)) {
						// looking for a translation
						$props = serendipity_fetchEntryProperties($eventData['id']);
						foreach($this->switch_keys as $key) {
							$eventData[$key] = $props['multilingual_' . $key . '_' . $this->showlang];
						}
					} else {
						// looking for default language
						$props = serendipity_fetchEntry('id', $eventData['id']);
						if (!is_array($props)) {
							return true;
						}
						foreach($this->switch_keys as $key) {
							$eventData[$key] = $props[$key];
						}	
					}
                    
					return true;
					break;

With this additional else clause, we can freely change between the default language and the translation.

One problem remains, and someone more familiar with the code than me will probably know:

After saving some changes (in default lang or translations), these are properly stored in db, but are not yet reflected in the entry form when it displays again (this also happens before applying my code changes). Apparently, the data for the form is requested _before_ the changes are written to the db -- or maybe the query results are cached somewhere?

If I try to get the entries through the native PHP API (mysql_query()), it seems to work -- but that's really bad style...

Someone can point me in the right direction? Thanks.

[garvinhicking]

Kitten, thanks a lot for your patch! I included it in the distro.

After saving some changes (in default lang or translations), these are properly stored in db, but are not yet reflected in the entry form when it displays again (this also happens before applying my code changes). Apparently, the data for the form is requested _before_ the changes are written to the db -- or maybe the query results are cached somewhere?

I don't really know what you mean. Can you give me a full example what I have to enter where so that I can reproduce this?

I tried this:

1. Click on "Create Entry"
2. Enter title, body text
3. Click on "Save"
4. Now change the language dropdown from "default" to "German".
5. Click on "Change language" next to the dropdown
6. The page reloads, the text frmo my previous entry remains. This is needed so that I can translate the text easily.
7. I enter the german title and body
8. I click on save.
9. Now I select a new language and switch to "French" and click on "Change language"
10. The text remains in german, so that I can translate it. I enter french title and body and click once again on save.
11. Now I see the french text displayed, and in the language dropdown I choose "German".
12. I click on "Choose language" and now I can edit/see the German text once again.

I think this is intended behaviour, right?

Thanks,
Garvin

[kitten]

Kitten, thanks a lot for your patch! I included it in the distro.

Hey, great, I did some useful stuff

1. Click on "Create Entry"
2. Enter title, body text
3. Click on "Save"
4. Now change the language dropdown from "default" to "German".
5. Click on "Change language" next to the dropdown
6. The page reloads, the text frmo my previous entry remains. This is needed so that I can translate the text easily.

Yes, I suppose this feature (to automagically get the text from the previous selected version) is meant to ease translation. From an interface point of view, it risks to confuse the user: he doesn't know if this text is just an unsaved copy from somewhere else or if it was entered before and is therefore already stored in db.

7. I enter the german title and body
8. I click on save.
9. Now I select a new language and switch to "French" and click on "Change language"
10. The text remains in german, so that I can translate it. I enter french title and body and click once again on save.
11. Now I see the french text displayed, and in the language dropdown I choose "German".
12. I click on "Choose language" and now I can edit/see the German text once again.

And now, try to edit any version (by changing some text), and after clicking "Save", the app re-displays the form again, right? But you won't find your previously changed text in the form fields (even if it has been stored in db), but the "old" version. Voilà the problem I have...

Thanks for your time

[garvinhicking]

I think I have a fix. I just committed this to the CVS as well.

Please change the backend_entryform part to this:

Code: Select all

                        foreach($this->switch_keys AS $key) {
                            if (empty($serendipity['POST'][$key]) && !empty($props['multilingual_' . $key . '_' . $this->showlang])) {
                                $eventData[$key] = $props['multilingual_' . $key . '_' . $this->showlang];
                            }
                        }

This now checks if a POST parameter is existing. if it is, it doesn't get overwritten by the old DB values.

Please tell me if that works out for you?

Regards,
Garvin

[Guest]

Doesn't work, sorry. I took a closer look...

Problem is, we only have one form on the page. There are 2 possibilities:

- The form has been submitted via a "Save" (in which case we want to see the new values, stored in $serendipity['POST'], on the next screen).

- Or the form has been submitted via a "Change language" (in which case we want to see the values of the chosen language as stored in DB).

So let's check it

OK, this is how it should work according to me -- you might want to add the feature that displays the content of the previously chosen language if the selected language has empty values.

Cheers

Heiner

Code: Select all

				case 'backend_entryform':
					if (!empty($this->showlang)) {
					
						// language is given (he wants a translation)
						$props = serendipity_fetchEntryProperties($eventData['id']);
						
						// this is a language change, not a save -- we want the DB values
						if (isset($serendipity['POST']['no_save'])) {
							foreach($this->switch_keys as $key) { 
								$eventData[$key] = $props['multilingual_' . $key . '_' . $this->showlang]; 
							}
						}						   
					} else {
					
						// language is NOT given (he wants the default language)
						$props = serendipity_fetchEntry('id', $eventData['id']);
						if (!is_array($props)) {
							return true;
						}
						
						// this is a language change, not a save -- we want the DB values
						if (isset($serendipity['POST']['no_save'])) {
							foreach($this->switch_keys as $key) {
								$eventData[$key] = $props[$key];
							} 
						}	
					}
				
					return true;
					break;

[kitten]

Hmm, forum is running under another domain, that broke my session. Above post is mine...

[wesley]

The 1.12 revision is certainly broken in my tests. I can't access my previous
Korean contents with it.

[garvinhicking]

I currently don't have time to test it. If anyone with CSV account has, please try it and commit it.

Otherwise I'll have a look on Tuesday...

Regards,
Garvin

[wesley]

I tested kitten's code and while it does what he said it should do, it does
not retain the previous language's contents to a 'new' language entry. It
seems to always query for the DB, so if there is none, the entry is cleared
and this makes it difficult for creating a translated work. This needs to be
corrected, IMO. I'll take a look at the code and perhaps commit the changes
later this evening.

EDIT: Okay, I think I have the solution. I'll go commit the code once I return home.

[kitten]

Hi,

I tested kitten's code and while it does what he said it should do, it does
not retain the previous language's contents to a 'new' language entry. It
seems to always query for the DB, so if there is none, the entry is cleared
and this makes it difficult for creating a translated work.

Yes, but see my explanation for this behaviour above -- IMO it's more confusing than helpful. If I want to work on a translation, I can always copy & paste the version I want to work with.

Anyway, in the meantime I continued to work on this plugin and I might propose a new version to the mailing list soon. The "copy" behaviour will be a configurable option. Additionally, it will introduce a new handling for the "default language".

Let me explain... Right now, the default language is based on the language the user has chosen for the admin interface, e.g. english. The default (english) version of the entry is stored in the entries table and this user can't even create an entry for an english version in the entryproperties table.

While this makes sense as long as _all_ admin users have chosen the same backend language, it becomes clumsy when another admin user with another language for the admin interface (let's say: German) accesses the entry.

He will see the previously entered english version as default, but he also has the possibility to create an english translation. Especially with the prefilled values for non-existing entries, he might make changes to his "english version" (that is only a copy of the default version) -- changes that will never show up in the default version, changes that admin No. 1 (with english user interface) will never see and can't even access! What a mess...

I tried to handle this differently. The user has only access to language versions thru the popup menu (in our case: english and german version), the default entry (in table entries) is handled transparently by the application to ensure BC in case the multilingual plugin ever gets removed.

In our case, the user could then create and edit the german and the english version and has an extra option to decide which version should be the default version (the one shown to the frontend user if no translation is available). The default version is then copied as "default version" to the entries table each time the record is saved.

Does that make sense? Is this something that is needed by the community? All comments, advice, caveats... are welcome

[randulo]

I have French (default) English, German.
In edit, I can see the proper texts in each language, but in weblog display, Default and 3rd languges are right, only language 2, English is wrong (displays default French).

When logged in, looking at weblog on the same browser, the language choice doesn't work as you probably know (always authors default). It would be nice if it could.