0963 rc-1 available

Nothing to say for now, except : no problem to upgrade to 0.9.6.3
No problem with special characters

Hi everyone,
I’ve downloaded and checked 0963 rc-1 . I have to edit my bulgarian lang files for the installer and manager and now everything is working fine.

After the installation, I selected "bulgarian" to be my default language for the manager and MODx gave me an error which concerned the TinyMCE Editor. I saw that in assets/plugins/tinymce3201/lang/bulgarian.inc.php was missing , so I added here (in this post) the bulgarian lang file to be included in the main package of MODx 0963 rc-1.

If any questions, just write me

Have a nice week

Thanks WildRose: committed at rev 4343

Fresh install OK, only one issue (which may be my stupidity) with Ditto.

Filtering on a TV value does not seem to work. Has this code been updated in any way?

Thanks a lot, rthrash

Today I decided to have a look at MODx installation I’ve done yesterday, and I saw "??..." sings in Manager - Manage Resources-Plugins in the list under plugins. When I switched to English langauage in Manager there was written "uncategorized", but in bulgarian I see this as "??..." (as in the attached JPG file).
I went thoroughly through bulgarian lang file and didn’t see untranslated line, then in the original file (english.inc.php) the only line I found was line 567 $_lang["no_category"] = ’uncategorized’; That line is translated in my lang file $_lang["no_category"] = ’некатегоризиран’; . I even added :



as a first line in bulgarian lang file , but nothing changed and I am still having these "??..." instead of "uncategorized".

Someone any ideas what am I doing wrong? Or missing something....




P.S. : Really Lost in Translation )))))))

You have to choose a bulgarian language file with the same encoding as you have chosen for the MODx character set. i.e. if you choose UTF-8 MODx charset, you need a UTF-8 encoded language file.

Quote from: OpenGeek at Oct 21, 2008, 07:26 PM

You have to choose a bulgarian language file with the same encoding as you have chosen for the MODx character set. i.e. if you choose UTF-8 MODx charset, you need a UTF-8 encoded language file.

Thanks for the answer, OpenGeek! All my language files are with UTF-8 encoding, and UTF-8 is selected for MODx character set also. If I didn’t do that , I would not see all the rest in ciryllic, as you can see in the JPG file, I attached to my previous post, I mean everything would be in "??...." , but these question marks appear only in Plugin- "uncategorized", which is really strange to me....Still fighting this )))

This is really odd indeed.

I have good news!!!!!!!!
As somebody wiser said "Everything happens for a reason", the problem is solved with a little help of a friend )) (Can you blame me, I am a translater, not a coder )

Our team coder and moderator here Lyubomir helped me solve the problem with "uncategorized" in Cyrillic and it appeared now correct in Manager. He changed the database connection method to SET_NAMES, instead of SET_CHARACTER_SET.
When I did my test installations, I always was choosing SET_CHARACTER_SET (the first thing that appeared in the Select bar), then UTF-8 everywhere (for the DB, for the Manager, for my language files), but seems this led me the problem with not translating "uncategorized" correctly and all those question marks that appeared.

So, the conclusion for me is that if someone whats to use Bulgarian language , he/she MUST select in the MODx installer SET_NAMES as a type of Database connection method and encoding UTF-8 and all be OK. )))


Just a suggestion : May be the above conclusion can be added as info tip in the file - install/lang/bulgarian/bulgarian.inc.php at
line 98 $_lang["connection_screen_connection_method"] = ’Начин на свързване - метод:’;

and in install/lang/english/english.inc.php just in case someone selects english as a default language for the Installer.

Thank you for the help, guys !!!!!

:)))))

This is because your database is in the wrong collation/character set to work properly with utf8 data. This means you are forcing translation of whatever collation it is to utf8 on the fly. If that’s what you intended great, but it is not the "correct" way to do it and generally means you are using a database/tables with latin1_swedish_ci collations to store utf8 data.