Details

    • Type: New Feature New Feature
    • Status: 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

      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
        2 kB
        Oleksiy Zagorskyi
      1. 1.result.png
        5 kB

        Activity

        Hide
        Oleksiy Zagorskyi added a comment -

        checked, i have no more remarks

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

        fixed, thank you.

        Show
        Konstantin Buravcov added a comment - fixed, thank you.
        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 -

        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 -

        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 -

        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 -

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

        DB patches merged: trunk 15681

        Show
        Konstantin Buravcov added a comment - DB patches merged: trunk 15681
        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 -

        patches created in branch ZBXNEXT-556-dbpatch

        Show
        Konstantin Buravcov added a comment - patches created in branch ZBXNEXT-556 -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
        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
        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
        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
        richlv added a comment -

        mm, reopening to set "fix for"

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

        closing then

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

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

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

        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
        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
        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, 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 -
        • 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

          People

          • Assignee:
            Konstantin Buravcov
            Reporter:
            Konstantin Buravcov
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: