ZABBIX FEATURE REQUESTS

• All translations are now made using gettext
• Wizard now checks if PHP gettext module is present
• .po dictionaries were generated based on zabbix translation files
• Translation 'profile' can be selected only if locale is present in the system

Konstantin, please update directory names according to ZBX-3211. I prepared my translation for a long time, but only now published.

And, I've tried this ZBXNEXT-556, but I'm not available for language selection at all.
If I am forced to set several another not English languages (in the old interface), then see the GUI error message as:
"Locale for language "ua_ua" is not found on the web server. Tried to set: ua_ua, ua_ua.utf8, ua_ua.iso885915. Unable to translate zabbix interface."

my environment:
FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:55:53 UTC 2010
gettext-0.18.1.1 GNU gettext package
php5-gettext-5.3.3_2 The gettext shared extension for php

Thank you for your comment, Oleksiy.

Most likely you are not able to select the translations because you don't have those locales installed on your system.

Can you provide the output of this command for your server?
ls /usr/share/locale
I don't have a freebsd server at hand right now, but I hope the command is right.

Konstantin, yes you right.
See attached "FreeBSD_8.1.txt" output command 'ls -1 /usr/share/locale'
In FreeBSD is used suffix "UTF-8" and my fixing for Ukrainian translation ZBX-3211 just in time. But I realized this earlier, before you create this ZBXNEXT.
See results '1.result.png' in a picture (I've already changed the php-code to "UTF-8" suffix and locale folder to "uk_UA".

And think and describe in few words, as we (translators) now can update the translation. Meaning the search for new untranslated strings than to change, etc. Are there plans to introduce something like a Pootle?

1. if php gettext support is missing, all we get is :
Fatal error: Call to undefined function _() in /home/main/usr/local/apache2/htdocs/dev/ZBXNEXT-556/include/locales/en_gb.inc.php on line 26
is it possible to do some more user friendly error reporting ?

2. administration -> locales is still there, and gives :
Undefined variable: transFrom[/home/main/usr/local/apache2/htdocs/dev/ZBXNEXT-556/locales.php:162]
Invalid argument supplied for foreach()[/home/main/usr/local/apache2/htdocs/dev/ZBXNEXT-556/locales.php:162]
is that page needed at all ?

other than that, seems to work mostly ok

zalex_ua, yes, availability of pootle and other gettext support tools was a significant motivator for this change - but i guess discussing that in more detail is best done on forum/irc

3. formatting of "*you are not able to choose some of the languages, because locales for them are not installed on the web server." slightly bugs me

maybe it can be positioned to the right of the dropdown, wrapped & in red ? or maybe just have an icon that would have a tooltip with that text (it's pretty long) ? icon could be an exclamation mark in a red circle or such...

Hint moved next to dropdown and is red now.

by now most things seem to be working mostly fine. summary of general points and unresolved nitpick items

1. if some locales are not available, it would be nice to have the error message wrap - now it extends the screen a lot;
2. pofiles are currently stored in individual, language coded directories - supposedly, the other way is to have language name in the file name, which would result in less extra navigation when using, for example, pootle. so files would be all placed in the "po" directory and named like zabbix-uk.po etc (it's possible to split them by project, so maybe zabbix-frontend-uk.po and zabbix-server-uk.po, but maybe it's not needed because of reused strings... to be discussed)
3. it was suggested to use language code only w/o regional code for languages where it is not available, otherwise some tools might need manual linking of such languages, or some scripting around them. so uk_UA would be just uk etc (so with filenames it would be zabbix-uk.po, not zabbix-uk_UA.po)
4. when pofiles are generated later on, they should contain references to where the string is used - that most likely would have to be done by whichever tool generates the files;
(there should be a description somewhere on how pofiles are generated, and if it is done using nonstandard tools, these tools should be available in the svn)
5. mo files are binary ones that are generated from the pofiles - they should not reside in the repository. instead, there should be some easy way to generate them for users, and they should be auto-generated in all releases, snapshots and other builds - a makefile target perhaps ?

once these things are sorted out, this might be ready for the great merge

1. wrapping done in dev branch rev 15527.

1. wrap done
2. messages.po -> frontend.po. could not remove LC_MESSAGES
3. names of directories changed
4. added task on DOCS
5. mo files deleted. Added task on 'makefile'

please, generate a fresh .po file from ZBX-3211. Now (in last trunk rev 15592) the Ukrainian .po file is very outdated.
This is the first and last time

ok, this one is getting close to merge
a couple more things :

1. french pofile should be regenerated (updated translation was merged);
2. placeholder and disambiguation usage should be documented (for examples see http://codex.wordpress.org/I18n_for_WordPress_Developers#Placeholders and http://codex.wordpress.org/I18n_for_WordPress_Developers#Disambiguation_by_context)

also, what about plurals (for example, see http://codex.wordpress.org/I18n_for_WordPress_Developers#Plurals)

mm, i'd say 'make gettext' should be called automatically by 'dist', and possibly also snapshot build system should be checked for existence of needed gettext tools (msgfmt etc)

• uk_UA and fr_FR translations were updated
• nightly build issue is solved
• some of the development docs are added

Merged to trunk rev 15656

closing then

mm, reopening to set "fix for"

Looks like that after the major upgrade, users will get an error that they will scare:

Locale for language "ru_ru" is not found on the web server...
Locale for language "fr_fr" is not found on the web server...
Locale for language "de_de" is not found on the web server...
.... and others locales

It seems you also should to update 'users' table - update 'lang' column:
change 'ua_ua' and 'uk_ua' to 'uk_UA'
'cn_zh' to 'zh_CN'
'sp_sp' to 'es_ES'
'ru_ru' to 'ru_RU'
others the same as Russian.

about changing 'ua_ua' to 'uk_ua' in 1.8.4 release - i tested and is no errors, web-interface simply display English version instead of Ukrainian. Ukrainian users need to simply reselect locale in their profile.

and. in my FreeBSD8.1 web-server the 'Latvian (LV)' selection is unavailable. only 'Latvian (LV)'.

hmm. thanks for the headsup.

so for 2.0 db patch must be created for the profiles table;
for 1.8.4... maybe the change to the ukrainian locale should be reverted (we can't issue a dbpatch) ?

I will work on 2.0 patch.
richlv, yes, it would be best to return ua_ua for 1.8.4

patches created in branch ZBXNEXT-556-dbpatch

reverted to ua_ua for 1.8;
patches look good to me, can be merged

DB patches merged: trunk 15681

It's not critical, but we all forget to update schema.sql and data.sql
Need "en_gb" replace to "en_GB".

... and existing DB schema should be updated in patches.

schema.sql and data.sql changed in trunk rev 17025.
Seems that patches already contain updates for all locales.

yes, schema.sql and data.sql already is updated, but "... existing DB >>>>> schema <<<<<<< should be updated in patches too."
Exactly existing SCHEMA !, not only existing DATA !

In the "./upgrades/dbpatches/2.0/mysql/patch/users.sql" need a:
ALTER TABLE users MODIFY userid bigint unsigned NOT NULL;
replace to:
ALTER TABLE users MODIFY userid bigint unsigned NOT NULL,
MODIFY lang varchar(5) DEFAULT 'en_GB' NOT NULL;

Oleksiy, thank you, I completely forgot about that Patches modified in rev 17052

hmmm, whole saga of these patches
Konstantin, you forgot a ";" trailing symbol for MYSQL patch:
ALTER TABLE users MODIFY lang VARCHAR(5) NOT NULL DEFAULT 'en_GB'

And usually developers write a single query in the patch, as I suggested in the previous comment. although I prefer a two query

fixed, thank you.

checked, i have no more remarks