[ZBXNEXT-556] Frontend i18n using PHP gettext module Created: 2010 Nov 10  Updated: 2011 Mar 31  Resolved: 2011 Jan 19

Status: Closed
Project: ZABBIX FEATURE REQUESTS
Component/s: None
Affects Version/s: 2.0.0
Fix Version/s: 1.9.1 (alpha)

Type: New Feature Request Priority: Major
Reporter: Konstantin Buravcov (Inactive) Assignee: Konstantin Buravcov (Inactive)
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

trunk


Attachments: PNG File 1.result.png     Text File FreeBSD_8.1.txt    

 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.



 Comments   
Comment by Konstantin Buravcov (Inactive) [ 2010 Nov 13 ]
  • 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
Comment by Oleksii Zagorskyi [ 2010 Nov 13 ]

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

Comment by Konstantin Buravcov (Inactive) [ 2010 Nov 13 ]

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.

Comment by Oleksii Zagorskyi [ 2010 Nov 13 ]

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?

Comment by richlv [ 2010 Nov 15 ]

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

Comment by richlv [ 2010 Nov 15 ]

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

Comment by richlv [ 2010 Nov 15 ]

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

Comment by Konstantin Buravcov (Inactive) [ 2010 Nov 16 ]

Hint moved next to dropdown and is red now.

Comment by richlv [ 2010 Nov 16 ]

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

Comment by richlv [ 2010 Nov 16 ]

1. wrapping done in dev branch rev 15527.

Comment by Konstantin Buravcov (Inactive) [ 2010 Nov 16 ]

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'

Comment by Oleksii Zagorskyi [ 2010 Nov 20 ]

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

Comment by richlv [ 2010 Nov 24 ]

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)

Comment by richlv [ 2010 Nov 24 ]

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)

Comment by Konstantin Buravcov (Inactive) [ 2010 Nov 24 ]
  • 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

Comment by richlv [ 2010 Nov 24 ]

closing then

Comment by richlv [ 2010 Nov 24 ]

mm, reopening to set "fix for"

Comment by Oleksii Zagorskyi [ 2010 Nov 24 ]

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.

Comment by Oleksii Zagorskyi [ 2010 Nov 24 ]

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

Comment by richlv [ 2010 Nov 24 ]

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

Comment by Konstantin Buravcov (Inactive) [ 2010 Nov 25 ]

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

Comment by Konstantin Buravcov (Inactive) [ 2010 Nov 25 ]

patches created in branch ZBXNEXT-556-dbpatch

Comment by richlv [ 2010 Nov 25 ]

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

Comment by Konstantin Buravcov (Inactive) [ 2010 Nov 25 ]

DB patches merged: trunk 15681

Comment by Oleksii Zagorskyi [ 2011 Jan 07 ]

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

Comment by Oleksii Zagorskyi [ 2011 Jan 07 ]

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

Comment by Konstantin Buravcov (Inactive) [ 2011 Jan 19 ]

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

Comment by Oleksii Zagorskyi [ 2011 Jan 19 ]

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;

Comment by Konstantin Buravcov (Inactive) [ 2011 Jan 20 ]

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

Comment by Oleksii Zagorskyi [ 2011 Jan 20 ]

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

Comment by Konstantin Buravcov (Inactive) [ 2011 Jan 21 ]

fixed, thank you.

Comment by Oleksii Zagorskyi [ 2011 Jan 21 ]

checked, i have no more remarks

Generated at Tue Mar 19 13:06:22 EET 2024 using Jira 9.12.4#9120004-sha1:625303b708afdb767e17cb2838290c41888e9ff0.