Thread: pgadmin4 l10n issues
Hello, I would like to to add Russian translation to pgAdmin 4, but having complete messages.po, I get incomplete UI translation. (See ss1.png attached.) I found two issues with the i18n in the current master. The first one is with web/pgadmin/tools/templates/js/translations.js. I don't understand why, but commit 4a91bcde makes the function return an empty array instead of translations. Patch for fixing it is attached. The second one is more complex and related to get_locale() method. This method is called when first gettext() invoked and it occurs on early stage, where the Preference module 'miscellaneous' is not registered yet. To be precise, first call to gettext() occurs when registering the 'Browser' module. But even if MiscModule will register first, it had to call _('Miscellaneous') before it gets registered. So I propose to implement some way to get current language when the misc preference module is not registered. Please look at the proposed patch. After these two fixes I get (almost) complete Russian interface (See ss2.png attached.) (May be some more strings should be made localizeable, but that is another question.) ------ Alexander Lakhin Postgres Professional: http://www.postgrespro.com The Russian Postgres Company
Attachment
Akshay, can you review/commit this, and look into why the remaining strings Alexander notes are not getting translated please?
Thanks.
On Thu, Oct 19, 2017 at 6:08 AM, Alexander Lakhin <exclusion@gmail.com> wrote:
Hello,
I would like to to add Russian translation to pgAdmin 4, but having complete messages.po, I get incomplete UI translation.
(See ss1.png attached.)
I found two issues with the i18n in the current master.
The first one is with web/pgadmin/tools/templates/js/translations.js.
I don't understand why, but commit 4a91bcde makes the function return an empty array instead of translations.
Patch for fixing it is attached.
The second one is more complex and related to get_locale() method. This method is called when first gettext() invoked and it occurs on early stage, where the Preference module 'miscellaneous' is not registered yet. To be precise, first call to gettext() occurs when registering the 'Browser' module. But even if MiscModule will register first, it had to call _('Miscellaneous') before it gets registered.
So I propose to implement some way to get current language when the misc preference module is not registered. Please look at the proposed patch.
After these two fixes I get (almost) complete Russian interface (See ss2.png attached.)
(May be some more strings should be made localizeable, but that is another question.)
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi Dave/Alexander,
On Thu, Oct 19, 2017 at 6:43 PM, Dave Page <dpage@pgadmin.org> wrote:
Did you forget to attach the patch?
Akshay, can you review/commit this, and look into why the remaining strings Alexander notes are not getting translated please?
Did you forget to attach the patch?
Thanks.On Thu, Oct 19, 2017 at 6:08 AM, Alexander Lakhin <exclusion@gmail.com> wrote:Hello,
I would like to to add Russian translation to pgAdmin 4, but having complete messages.po, I get incomplete UI translation.
(See ss1.png attached.)
I found two issues with the i18n in the current master.
The first one is with web/pgadmin/tools/templates/js/translations.js.
I don't understand why, but commit 4a91bcde makes the function return an empty array instead of translations.
Patch for fixing it is attached.
The second one is more complex and related to get_locale() method. This method is called when first gettext() invoked and it occurs on early stage, where the Preference module 'miscellaneous' is not registered yet. To be precise, first call to gettext() occurs when registering the 'Browser' module. But even if MiscModule will register first, it had to call _('Miscellaneous') before it gets registered.
So I propose to implement some way to get current language when the misc preference module is not registered. Please look at the proposed patch.
After these two fixes I get (almost) complete Russian interface (See ss2.png attached.)
(May be some more strings should be made localizeable, but that is another question.)
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Should be upthread I believe - archives.postgresql.org if you cannot find it?
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK:http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK:http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi Dave/Alexander,On Thu, Oct 19, 2017 at 6:43 PM, Dave Page <dpage@pgadmin.org> wrote:Akshay, can you review/commit this, and look into why the remaining strings Alexander notes are not getting translated please?
Did you forget to attach the patch?Thanks.On Thu, Oct 19, 2017 at 6:08 AM, Alexander Lakhin <exclusion@gmail.com> wrote:Hello,
I would like to to add Russian translation to pgAdmin 4, but having complete messages.po, I get incomplete UI translation.
(See ss1.png attached.)
I found two issues with the i18n in the current master.
The first one is with web/pgadmin/tools/templates/js/translations.js.
I don't understand why, but commit 4a91bcde makes the function return an empty array instead of translations.
Patch for fixing it is attached.
The second one is more complex and related to get_locale() method. This method is called when first gettext() invoked and it occurs on early stage, where the Preference module 'miscellaneous' is not registered yet. To be precise, first call to gettext() occurs when registering the 'Browser' module. But even if MiscModule will register first, it had to call _('Miscellaneous') before it gets registered.
So I propose to implement some way to get current language when the misc preference module is not registered. Please look at the proposed patch.
After these two fixes I get (almost) complete Russian interface (See ss2.png attached.)
(May be some more strings should be made localizeable, but that is another question.)
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
--Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Hi Ashesh,
23.10.2017 08:21, Ashesh Vashi wrote:
23.10.2017 08:21, Ashesh Vashi wrote:
No, I didn't. You can find all my attached files here:Hi Dave/Alexander,On Thu, Oct 19, 2017 at 6:43 PM, Dave Page <dpage@pgadmin.org> wrote:Akshay, can you review/commit this, and look into why the remaining strings Alexander notes are not getting translated please?
Did you forget to attach the patch?
https://www.postgresql.org/message-id/5c7914c8-db5f-cb70-a81e-6e9145039935%40gmail.com
Best regards,
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Oct 24, 2017 at 6:08 PM, Alexander Lakhin <exclusion@gmail.com> wrote:
Hi Ashesh,
23.10.2017 08:21, Ashesh Vashi wrote:No, I didn't. You can find all my attached files here:Hi Dave/Alexander,On Thu, Oct 19, 2017 at 6:43 PM, Dave Page <dpage@pgadmin.org> wrote:Akshay, can you review/commit this, and look into why the remaining strings Alexander notes are not getting translated please?
Did you forget to attach the patch?
https://www.postgresql.org/message-id/5c7914c8-db5f-cb70- a81e-6e9145039935%40gmail.com
I reviewed your patches.
I have committed the first patch.
About the second patch, I understood the issue.
I prefer another approach, instead of proposed by you.
Problem with the approach, you suggested, is: label for 'miscellaneous' Preference object will be always None.
Instead - read the 'raw_value' from the configuration database.
-- Thanks, Ashesh
Best regards,
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachment
24.10.2017 17:17, Ashesh Vashi wrote:
Yes, your approach is better (I tried to minimize the fix and didn't notice the label change).On Tue, Oct 24, 2017 at 6:08 PM, Alexander Lakhin <exclusion@gmail.com> wrote:Hi Ashesh,
23.10.2017 08:21, Ashesh Vashi wrote:No, I didn't. You can find all my attached files here:Hi Dave/Alexander,On Thu, Oct 19, 2017 at 6:43 PM, Dave Page <dpage@pgadmin.org> wrote:Akshay, can you review/commit this, and look into why the remaining strings Alexander notes are not getting translated please?
Did you forget to attach the patch?
https://www.postgresql.org/message-id/5c7914c8-db5f-cb70- a81e-6e9145039935%40gmail.com I reviewed your patches.I have committed the first patch.About the second patch, I understood the issue.I prefer another approach, instead of proposed by you.
But with the patch applied I get the following error:
File "/data/sources/pgadmin4/lib/python2.7/site-packages/pgadmin4/pgadmin/__init__.py", line 246, in get_locale
'miscellaneous', 'user_language'
File "/data/sources/pgadmin4/lib/python2.7/site-packages/pgadmin4/pgadmin/utils/preferences.py", line 502, in raw_value
).filter_by(uid=current_user.id).first()
File "/data/sources/pgadmin4/lib/python2.7/site-packages/werkzeug/local.py", line 338, in __getattr__
return getattr(self._get_current_object(), name)
AttributeError: 'AnonymousUser' object has no attribute 'id'
Best regards,
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Oct 24, 2017 at 8:35 PM, Alexander Lakhin <exclusion@gmail.com> wrote:
24.10.2017 17:17, Ashesh Vashi wrote:Yes, your approach is better (I tried to minimize the fix and didn't notice the label change).On Tue, Oct 24, 2017 at 6:08 PM, Alexander Lakhin <exclusion@gmail.com> wrote:Hi Ashesh,
23.10.2017 08:21, Ashesh Vashi wrote:No, I didn't. You can find all my attached files here:Hi Dave/Alexander,On Thu, Oct 19, 2017 at 6:43 PM, Dave Page <dpage@pgadmin.org> wrote:Akshay, can you review/commit this, and look into why the remaining strings Alexander notes are not getting translated please?
Did you forget to attach the patch?
https://www.postgresql.org/message-id/5c7914c8-db5f-cb70-a81 e-6e9145039935%40gmail.com I reviewed your patches.I have committed the first patch.About the second patch, I understood the issue.I prefer another approach, instead of proposed by you.
But with the patch applied I get the following error:
File "/data/sources/pgadmin4/lib/python2.7/site-packages/ pgadmin4/pgadmin/__init__.py", line 246, in get_locale
'miscellaneous', 'user_language'
File "/data/sources/pgadmin4/lib/python2.7/site-packages/ pgadmin4/pgadmin/utils/ preferences.py", line 502, in raw_value
).filter_by(uid=current_user.id).first()
File "/data/sources/pgadmin4/lib/python2.7/site-packages/ werkzeug/local.py", line 338, in __getattr__
return getattr(self._get_current_object(), name)
AttributeError: 'AnonymousUser' object has no attribute 'id'
Looks like - I missed to logout, and test.
Please find the updated patch.
-- Thanks, Ashesh
Best regards,
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachment
24.10.2017 18:11, Ashesh Vashi wrote:
Now the error is gone but I get no right locale.Looks like - I missed to logout, and test.Please find the updated patch.
The issue is with Desktop mode (see "if config.SERVER_MODE is False:" in web/pgadmin/__init__.py).
-- Thanks, Ashesh
Best regards,
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
On Tue, Oct 24, 2017 at 9:11 PM, Alexander Lakhin <exclusion@gmail.com> wrote:
24.10.2017 18:11, Ashesh Vashi wrote:Now the error is gone but I get no right locale.Looks like - I missed to logout, and test.Please find the updated patch.
The issue is with Desktop mode (see "if config.SERVER_MODE is False:" in web/pgadmin/__init__.py).
Did you restart the pgAdmin4/reload after changing the language?
-- Thanks, Ashesh
-- Thanks, Ashesh
Best regards,
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
25.10.2017 14:52, Ashesh Vashi wrote:
Yes, I restarted it.On Tue, Oct 24, 2017 at 9:11 PM, Alexander Lakhin <exclusion@gmail.com> wrote:24.10.2017 18:11, Ashesh Vashi wrote:Now the error is gone but I get no right locale.Looks like - I missed to logout, and test.Please find the updated patch.
The issue is with Desktop mode (see "if config.SERVER_MODE is False:" in web/pgadmin/__init__.py).Did you restart the pgAdmin4/reload after changing the language?
The issue is with the current_user.
To reproduce it you can perform rm ~/.pgadmin/sessions/* and then restart pgAdmin4/reload the web interface.
As I understand, the modules are registered (and get_locales() first called) before user_login is performed in before_request.
So on very first call to get_locale() you can't use the current_user object.
Please look at v4 of the patch.
Best regards,
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company
Attachment
On Fri, Oct 27, 2017 at 6:45 PM, Alexander Lakhin <exclusion@gmail.com> wrote:
25.10.2017 14:52, Ashesh Vashi wrote:Yes, I restarted it.On Tue, Oct 24, 2017 at 9:11 PM, Alexander Lakhin <exclusion@gmail.com> wrote:24.10.2017 18:11, Ashesh Vashi wrote:Now the error is gone but I get no right locale.Looks like - I missed to logout, and test.Please find the updated patch.
The issue is with Desktop mode (see "if config.SERVER_MODE is False:" in web/pgadmin/__init__.py).Did you restart the pgAdmin4/reload after changing the language?
The issue is with the current_user.
To reproduce it you can perform rm ~/.pgadmin/sessions/* and then restart pgAdmin4/reload the web interface.
As I understand, the modules are registered (and get_locales() first called) before user_login is performed in before_request.
So on very first call to get_locale() you can't use the current_user object.
Please look at v4 of the patch.
Thanks - I have committed the patch.
-- Thanks,
Ashesh Vashi
Best regards,
------
Alexander Lakhin
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company