Обсуждение: i18n GER, suggestions, questions
Hey pgAdmin-Hackers / Dave Page,
here are my suggestions and questions regarding the translation of pgAdmin!
Patches
i18n-cannot.diff
Replaced all occurrences of "can not" with "cannot".
i18n-correction.diff
(De)Capitalized strings to fit the common/usual format, corrected spelling, removed unnecessary characters.
i18n-definition.diff
Unified usage of "definition incomplete".
i18n-quotes.diff
Removed unnecessary quotes. Could be wrong.
i18n-translation.diff
GERMAN TRANSLATION! yeah!
i18n-trim.diff
Removed two linebreaks to improve translation experience.
Questions
Can we change the way " + err.errormsg + " is translated? Same for "" + err.errormsg + "", "" + error_msg + "", "" + res.info + "" in several other files. For me it makes no sense to translate variables rather than their value.
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\templates\table\js\table.js, ...)
Is there a way to combine separated translatable string like the one below into one? It's difficult to translate the strings separated without knowing what their meaning is later when they stand together.
'{{ _('Are you sure you wish to move objects ') }}'
+ '"' + args.old_tblspc + '"'
+ '{{ _(' to ') }}'
+ '"' + args.tblspc + '"?',
(pgadmin4\web\pgadmin\browser\server_groups\servers\tablespaces\templates\tablespaces\js\tablespaces.js)
Is "catalog_object_column" something that should be translated? Same for "help_str", "index_constraint", "pga_jobs".
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\catalog_objects\columns\templates\catalog_object_column\js\catalog_object_column.js)
(pgadmin4\web\pgadmin\preferences\__init__.py)
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\constraints\index_constraint\__init__.py)
(pgadmin4\web\pgadmin\browser\server_groups\servers\pgagent\templates\pga_job\js\pga_job.js)
We got three different notations for "Column name cannot be empty": Are they all needed? As I'm new to pgAdmin I don't know exactly where these strings are used. Can we unify the capitalization and exclamation mark usage here?
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\foreign_tables\templates\foreign_tables\js\foreign_tables.js)
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\column\templates\column\js\column.js)
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\indexes\templates\index\js\index.js)
What does "in explain" mean? That's not clear to me.
(pgadmin4\web\pgadmin\tools\sqleditor\templates\sqleditor\js\sqleditor.js)
Is "server#{1}:{2}:\n{0}" the correct format? To me it looks like there is at least a missing space.
(pgadmin4\web\pgadmin\utils\driver\psycopg2\__init__.py)
Can we reformat "'{{ _('Please specify columns for ') }}' + '{{ node_label }}'" for German translation? Same problem as with the multiline string above (#2). The German sentence structure requires "node_label" to be between the words of "Please specify columns for".
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\constraints\index_constraint\templates\index_constraint\js\index_constraint.js)
Thanks in advance and good night. *-*
Вложения
Hi!
On Sun, Apr 2, 2017 at 4:03 AM, Jonas Thelemann
<e-mail@jonas-thelemann.de> wrote:
> Hey pgAdmin-Hackers / Dave Page,
>
> here are my suggestions and questions regarding the translation of pgAdmin!
>
>
> Patches
>
> i18n-cannot.diff
>
> Replaced all occurrences of "can not" with "cannot".
Applied.
> i18n-correction.diff
>
> (De)Capitalized strings to fit the common/usual format, corrected spelling,
> removed unnecessary characters.
Applied with a couple of changes removed (maybe some
capitalisation-blindness, as you were un-fixing some strings :-)
> i18n-definition.diff
>
> Unified usage of "definition incomplete".
>
>
> i18n-quotes.diff
>
> Removed unnecessary quotes. Could be wrong.
All of the above applied.
>
> i18n-translation.diff
>
> GERMAN TRANSLATION! yeah!
\o/
>
> i18n-trim.diff
>
> Removed two linebreaks to improve translation experience.
Hmm, I've applied that, but expect an ongoing battle between gettext and PEP8...
> Questions
>
> Can we change the way " + err.errormsg + " is translated? Same for "" +
> err.errormsg + "", "" + error_msg + "", "" + res.info + "" in several other
> files. For me it makes no sense to translate variables rather than their
> value.
> (pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\templates\table\js\table.js,
> ...)
Yes, they should really use placeholders, not string concatenation.
> Is there a way to combine separated translatable string like the one below
> into one? It's difficult to translate the strings separated without knowing
> what their meaning is later when they stand together.
> '{{ _('Are you sure you wish to move objects ') }}'
> + '"' + args.old_tblspc + '"'
> + '{{ _(' to ') }}'
> + '"' + args.tblspc + '"?',
> (pgadmin4\web\pgadmin\browser\server_groups\servers\tablespaces\templates\tablespaces\js\tablespaces.js)
That should also be a single string with placeholders.
> Is "catalog_object_column" something that should be translated? Same for
> "help_str", "index_constraint", "pga_jobs".
>
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\catalog_objects\columns\templates\catalog_object_column\js\catalog_object_column.js)
> (pgadmin4\web\pgadmin\preferences\__init__.py)
>
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\constraints\index_constraint\__init__.py)
> (pgadmin4\web\pgadmin\browser\server_groups\servers\pgagent\templates\pga_job\js\pga_job.js)
No, I believe they're all strings that are never seen (though similar
strings in other files may be).
> We got three different notations for "Column name cannot be empty": Are they
> all needed? As I'm new to pgAdmin I don't know exactly where these strings
> are used. Can we unify the capitalization and exclamation mark usage here?
>
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\foreign_tables\templates\foreign_tables\js\foreign_tables.js)
> (pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\column\templates\column\js\column.js)
> (pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\indexes\templates\index\js\index.js)
So those strings should match the labels on the dialogue (and I'm
trying to eliminate use of !), e.g.
<field name> cannot be empty.
So, if the field is labelled "Column name" then the error should be
"Column name cannot be empty.". The field names should all be init-cap
for the first word only, unless the second word is a keyword of some
kind, or an acronym.
> What does "in explain" mean? That's not clear to me.
> (pgadmin4\web\pgadmin\tools\sqleditor\templates\sqleditor\js\sqleditor.js)
If you mean the error messages, then I think that's bad phrasing. I
believe it should be:
An error occurred while setting the EXPLAIN VERBOSE option.
> Is "server#{1}:{2}:\n{0}" the correct format? To me it looks like there is
> at least a missing space.
> (pgadmin4\web\pgadmin\utils\driver\psycopg2\__init__.py)
I'd maybe replace:
Failed to create cursor for psycopg2 connection with error message for
the server#{1}:{2}:\n{0}
with something like:
Failed to create a cursor for the psycopg2 connection to server #{1},
database: {2}. Error:\n{0]
> Can we reformat "'{{ _('Please specify columns for ') }}' + '{{ node_label
> }}'" for German translation? Same problem as with the multiline string above
> (#2). The German sentence structure requires "node_label" to be between the
> words of "Please specify columns for".
>
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\constraints\index_constraint\templates\index_constraint\js\index_constraint.js)
Yes, that's another case where we should be using parameters, not concatenation.
Can you provide patches for the changes above?
Thanks for your hard work.
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Thanks for committing! :)
>> i18n-trim.diff
>>
>> Removed two linebreaks to improve translation experience.
> Hmm, I've applied that, but expect an ongoing battle between gettext and PEP8...
>
Ok, I had to look up what PEP8 is :D
So the only problem was that, with those newlines I removed, the
translatable strings contained many extremely useless whitespaces
inserted by the code indentation. I guess a workaround could be to just
remove the spaces like I've seen somewhere else already:
----------
----------"""abc \n
def"""
----------
instead of:
----------
----------"""abc def"""
----------
and:
----------
----------"""abc \n
----------def"""
----------
... where dashes represent whitespaces.
But that is just an idea and something somebody with better Python
knowledge should decide :)
> Can you provide patches for the changes above?
Yes, I can do that, but not right away. I currently have some other
things to complete in the next few weeks, but I'll try to fit that in.
Am 05.04.2017 um 16:23 schrieb Dave Page:
> Hi!
>
> On Sun, Apr 2, 2017 at 4:03 AM, Jonas Thelemann
> <e-mail@jonas-thelemann.de> wrote:
>> Hey pgAdmin-Hackers / Dave Page,
>>
>> here are my suggestions and questions regarding the translation of pgAdmin!
>>
>>
>> Patches
>>
>> i18n-cannot.diff
>>
>> Replaced all occurrences of "can not" with "cannot".
> Applied.
>
>> i18n-correction.diff
>>
>> (De)Capitalized strings to fit the common/usual format, corrected spelling,
>> removed unnecessary characters.
> Applied with a couple of changes removed (maybe some
> capitalisation-blindness, as you were un-fixing some strings :-)
>
>> i18n-definition.diff
>>
>> Unified usage of "definition incomplete".
>>
>>
>> i18n-quotes.diff
>>
>> Removed unnecessary quotes. Could be wrong.
> All of the above applied.
>
>> i18n-translation.diff
>>
>> GERMAN TRANSLATION! yeah!
> \o/
>
>> i18n-trim.diff
>>
>> Removed two linebreaks to improve translation experience.
> Hmm, I've applied that, but expect an ongoing battle between gettext and PEP8...
>
>> Questions
>>
>> Can we change the way " + err.errormsg + " is translated? Same for "" +
>> err.errormsg + "", "" + error_msg + "", "" + res.info + "" in several other
>> files. For me it makes no sense to translate variables rather than their
>> value.
>> (pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\templates\table\js\table.js,
>> ...)
> Yes, they should really use placeholders, not string concatenation.
>
>> Is there a way to combine separated translatable string like the one below
>> into one? It's difficult to translate the strings separated without knowing
>> what their meaning is later when they stand together.
>> '{{ _('Are you sure you wish to move objects ') }}'
>> + '"' + args.old_tblspc + '"'
>> + '{{ _(' to ') }}'
>> + '"' + args.tblspc + '"?',
>> (pgadmin4\web\pgadmin\browser\server_groups\servers\tablespaces\templates\tablespaces\js\tablespaces.js)
> That should also be a single string with placeholders.
>
>> Is "catalog_object_column" something that should be translated? Same for
>> "help_str", "index_constraint", "pga_jobs".
>>
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\catalog_objects\columns\templates\catalog_object_column\js\catalog_object_column.js)
>> (pgadmin4\web\pgadmin\preferences\__init__.py)
>>
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\constraints\index_constraint\__init__.py)
>> (pgadmin4\web\pgadmin\browser\server_groups\servers\pgagent\templates\pga_job\js\pga_job.js)
> No, I believe they're all strings that are never seen (though similar
> strings in other files may be).
>
>> We got three different notations for "Column name cannot be empty": Are they
>> all needed? As I'm new to pgAdmin I don't know exactly where these strings
>> are used. Can we unify the capitalization and exclamation mark usage here?
>>
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\foreign_tables\templates\foreign_tables\js\foreign_tables.js)
>> (pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\column\templates\column\js\column.js)
>> (pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\indexes\templates\index\js\index.js)
> So those strings should match the labels on the dialogue (and I'm
> trying to eliminate use of !), e.g.
>
> <field name> cannot be empty.
>
> So, if the field is labelled "Column name" then the error should be
> "Column name cannot be empty.". The field names should all be init-cap
> for the first word only, unless the second word is a keyword of some
> kind, or an acronym.
>
>> What does "in explain" mean? That's not clear to me.
>> (pgadmin4\web\pgadmin\tools\sqleditor\templates\sqleditor\js\sqleditor.js)
> If you mean the error messages, then I think that's bad phrasing. I
> believe it should be:
>
> An error occurred while setting the EXPLAIN VERBOSE option.
>
>
>> Is "server#{1}:{2}:\n{0}" the correct format? To me it looks like there is
>> at least a missing space.
>> (pgadmin4\web\pgadmin\utils\driver\psycopg2\__init__.py)
> I'd maybe replace:
>
> Failed to create cursor for psycopg2 connection with error message for
> the server#{1}:{2}:\n{0}
>
> with something like:
>
> Failed to create a cursor for the psycopg2 connection to server #{1},
> database: {2}. Error:\n{0]
>
>
>> Can we reformat "'{{ _('Please specify columns for ') }}' + '{{ node_label
>> }}'" for German translation? Same problem as with the multiline string above
>> (#2). The German sentence structure requires "node_label" to be between the
>> words of "Please specify columns for".
>>
(pgadmin4\web\pgadmin\browser\server_groups\servers\databases\schemas\tables\constraints\index_constraint\templates\index_constraint\js\index_constraint.js)
> Yes, that's another case where we should be using parameters, not concatenation.
>
> Can you provide patches for the changes above?
>
> Thanks for your hard work.
>
On Thu, Apr 6, 2017 at 2:27 AM, Jonas Thelemann
<e-mail@jonas-thelemann.de> wrote:
> Thanks for committing! :)
>
>>> i18n-trim.diff
>>>
>>> Removed two linebreaks to improve translation experience.
>>
>> Hmm, I've applied that, but expect an ongoing battle between gettext and
>> PEP8...
>>
> Ok, I had to look up what PEP8 is :D
> So the only problem was that, with those newlines I removed, the
> translatable strings contained many extremely useless whitespaces inserted
> by the code indentation. I guess a workaround could be to just remove the
> spaces like I've seen somewhere else already:
>
> ----------
> ----------"""abc \n
> def"""
> ----------
>
> instead of:
>
> ----------
> ----------"""abc def"""
> ----------
>
> and:
>
> ----------
> ----------"""abc \n
> ----------def"""
> ----------
>
> ... where dashes represent whitespaces.
> But that is just an idea and something somebody with better Python knowledge
> should decide :)
Hmm, yeah. So we really need the messages to be a single string, as
the splits may not make sense in other languages, so this won't work:
>>> print("Hello " \
... "How are you")
This will result in extra whitespace:
>>> print("Hello \
... How are you")
Whilst this will result in an extra line break:
>>> print("""Hello
... How are you""")
I'm beginning to think we have no choice but to ignore PEP8 and not
allow strings to wrap except where we want them to. I can't find
anything on Google about other alternatives - EDB guys, any
suggestions?
>> Can you provide patches for the changes above?
>
> Yes, I can do that, but not right away. I currently have some other things
> to complete in the next few weeks, but I'll try to fit that in.
Cool, thanks!
--
Dave Page
Blog: http://pgsnake.blogspot.com
Twitter: @pgsnake
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company