Re: i18n GER, suggestions, questions - Mailing list pgadmin-hackers
From | Jonas Thelemann |
---|---|
Subject | Re: i18n GER, suggestions, questions |
Date | |
Msg-id | 573d05d6-92f3-ebb3-830f-916dd0f772af@jonas-thelemann.de Whole thread Raw |
In response to | Re: i18n GER, suggestions, questions (Dave Page <dpage@pgadmin.org>) |
Responses |
Re: i18n GER, suggestions, questions
|
List | pgadmin-hackers |
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. >
pgadmin-hackers by date: