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




--
Sent via pgadmin-hackers mailing list (pgadmin-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgadmin-hackers

Reply via email to