ZABBIX FEATURE REQUESTS

Frontend i18n using PHP gettext module

Details

  • Type: New Feature New Feature
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.0.0
  • Fix Version/s: 1.9.1 (alpha)
  • Component/s: None
  • Labels:
    None
  • Environment:
    trunk
  • Zabbix ID:
    NA

Description

As discussed, a gettext support should be added to frontend.

1. All strings that present in current locale files should be embed for gettext translation;
2. po/mo dictionaries should be generated;
3. All new strings should be put directly into code (not in includes) embed as gettext functions;
4. Zabbix gets gettext PHP module dependency, so a check in the wizard should be added.
  1. FreeBSD_8.1.txt
    2010 Nov 13 19:53
    2 kB
    Oleksiy Zagorskyi
  1. 1.result.png
    5 kB
    2010 Nov 13 19:53

Activity

Hide
Konstantin Buravcov added a comment -
  • 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
Show
Konstantin Buravcov added a comment -
  • 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
Hide
Oleksiy Zagorskyi added a comment -

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

Show
Oleksiy Zagorskyi added a comment - 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
Hide
Konstantin Buravcov added a comment -

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.

Show
Konstantin Buravcov added a comment - 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.
Hide
Oleksiy Zagorskyi added a comment -

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?

Show
Oleksiy Zagorskyi added a comment - 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?
Hide
richlv added a comment -

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

Show
richlv added a comment - 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
Hide
richlv added a comment -

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

Show
richlv added a comment - 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
Hide
richlv added a comment -

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...

Show
richlv added a comment - 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...
Hide
Konstantin Buravcov added a comment -

Hint moved next to dropdown and is red now.

Show
Konstantin Buravcov added a comment - Hint moved next to dropdown and is red now.
Hide
richlv added a comment - - edited

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

Show
richlv added a comment - - edited 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
Hide
richlv added a comment -

1. wrapping done in dev branch rev 15527.

Show
richlv added a comment - 1. wrapping done in dev branch rev 15527.
Hide
Konstantin Buravcov added a comment -

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'

Show
Konstantin Buravcov added a comment - 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'
Hide
Oleksiy Zagorskyi added a comment -

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

Show
Oleksiy Zagorskyi added a comment - 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
Hide
richlv added a comment -

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)

Show
richlv added a comment - 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)
Hide
richlv added a comment -

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)

Show
richlv added a comment - 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)
Hide
Konstantin Buravcov added a comment - - edited
  • 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

Show
Konstantin Buravcov added a comment - - edited
  • 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
Hide
richlv added a comment -

closing then

Show
richlv added a comment - closing then
Hide
richlv added a comment -

mm, reopening to set "fix for"

Show
richlv added a comment - mm, reopening to set "fix for"
Hide
Oleksiy Zagorskyi added a comment -

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.

Show
Oleksiy Zagorskyi added a comment - 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.
Hide
Oleksiy Zagorskyi added a comment -

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

Show
Oleksiy Zagorskyi added a comment - and. in my FreeBSD8.1 web-server the 'Latvian (LV)' selection is unavailable. only 'Latvian (LV)'.
Hide
richlv added a comment -

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) ?

Show
richlv added a comment - 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) ?
Hide
Konstantin Buravcov added a comment -

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

Show
Konstantin Buravcov added a comment - I will work on 2.0 patch. richlv, yes, it would be best to return ua_ua for 1.8.4
Hide
Konstantin Buravcov added a comment -

patches created in branch ZBXNEXT-556-dbpatch

Show
Konstantin Buravcov added a comment - patches created in branch ZBXNEXT-556-dbpatch
Hide
richlv added a comment -

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

Show
richlv added a comment - reverted to ua_ua for 1.8; patches look good to me, can be merged
Hide
Konstantin Buravcov added a comment -

DB patches merged: trunk 15681

Show
Konstantin Buravcov added a comment - DB patches merged: trunk 15681
Hide
Oleksiy Zagorskyi added a comment -

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

Show
Oleksiy Zagorskyi added a comment - It's not critical, but we all forget to update schema.sql and data.sql Need "en_gb" replace to "en_GB".
Hide
Oleksiy Zagorskyi added a comment -

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

Show
Oleksiy Zagorskyi added a comment - ... and existing DB schema should be updated in patches.
Hide
Konstantin Buravcov added a comment -

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

Show
Konstantin Buravcov added a comment - schema.sql and data.sql changed in trunk rev 17025. Seems that patches already contain updates for all locales.
Hide
Oleksiy Zagorskyi added a comment -

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;

Show
Oleksiy Zagorskyi added a comment - 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;
Hide
Konstantin Buravcov added a comment -

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

Show
Konstantin Buravcov added a comment - Oleksiy, thank you, I completely forgot about that Patches modified in rev 17052
Hide
Oleksiy Zagorskyi added a comment -

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

Show
Oleksiy Zagorskyi added a comment - 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
Hide
Konstantin Buravcov added a comment -

fixed, thank you.

Show
Konstantin Buravcov added a comment - fixed, thank you.
Hide
Oleksiy Zagorskyi added a comment -

checked, i have no more remarks

Show
Oleksiy Zagorskyi added a comment - checked, i have no more remarks

People

Vote (0)
Watch (0)

Dates

  • Created:
    Updated:
    Resolved: