Is there some code change that has impact to the display of characters?
After upgrading I noticed that album, image etc description text were without characters like õ, ä, ö, ü. They were disappeared also from editor in backend.
In database all these characters were present.
After I corrected the text the dotted/tilded chars looked normal but in database, the text was surrounded by a:1:{s:5:"et_EE";s:235:" ";} and i.e "õ" converted to "õ"
Correction of these characters back to normal removed the text from frontend.
Then, after I removed surrounding a:1:{s:5:"et_EE";s:235:" ";} the text was displayed again (without õ, ä, ö, ü as mentioned above.
Multilingual mode is turned off. DB charset is UTF8 unicode, set both in backend and database. Setting it in DB from utf8_unicode_ci to utf8_estonian_ci didn't change anything.
Zenphoto
Comments
We are still investigating why and what.
Regarding the serialized strings like `a:1:{s:5:"et_EE";s:235:" ";}` please see here: http://www.zenphoto.org/news/problems-with-languages#in-my-database-there-are-fields-that-contain-weird
About serializing. Wouldn't it make more sense (in future) to have a special table instead for translated content? With possible name zp_translated_content
This table would have fields for locale, title, desc, content and of course also e.g image_id, album_id, news_id, category_id ... or parent_id and type (containing type names like 'album', 'image' etc
I mean the actual fields with original info would remain in place (otherwise where the image original info would be written?), just (again) without serializing.
But all translations would be written in zp_translated_content.
If multilingual mode is on AND translation in selected language is available then this translation would be displayed, otherwise the original content.
And nothing would happen with existing translations when switching between mono/multilingual mode.
Why I think it would be good idea - in some cases a webmaster would like to bind the contents of 2 sites (often we prefer to reuse existing data instead of duplicating it, right?).
I just have one particular idea (using ZP and, from other hand, Joomla component Fabrik) and I believe 2 joined tables and fields with plain text strings would make it easier than one single table with serialized data. Especially when this data should be (partially) managed from both sites.
Should I open an issue in GitHub?
But yes, feel free to open a ticket to discuss this. It would have to be done that way no issues are created with existing strings and it can get complicated since it needs to cover all other kinds of fields that support multilingual stuff like option fields. This could be quite a change (not on the list actually for 1.4.6). Since sbillard is the main author of the multilingual stuff it will be his decision.