Hello all
I'm new in dev list, but I've been working in translations for some time.
I would like to standardize some grass messages, according to what is proposed in http://grass.gdf-hannover.de/wiki/Development_Specs (please check last changes) in order to ease the work for translators and get a more consistent program. I don't know if standard messages proposed in wiki can already be used or if discussion is still open. Any feedback is welcome. If no objections are reported, I will start changing messages in the next days, at least the most obvious.
Regards
Carlos Dávila (translation manager)
Carlos Dávila wrote:
I'm new in dev list, but I've been working in translations for some
time. I would like to standardize some grass messages, according to
what is proposed in
http://grass.gdf-hannover.de/wiki/Development_Specs (please check
last changes) in order to ease the work for translators and get a
more consistent program. I don't know if standard messages proposed in
wiki can already be used or if discussion is still open. Any feedback
is welcome. If no objections are reported, I will start changing
messages in the next days, at least the most obvious.
The ideas on the wiki page are just the opinions of a few of us who
edited the page AFAICT, not a full consensus reached on the -dev mailing
list which it needs to be before any mass change. So that it can be
formalized and the discussion closed, I too would ask everyone to review
what's listed there, and discuss here. There are several unresolved
questions there which need to be answered.
At least I hope with g.message and G_*message() we have all the tools we
need now? My only gripe with G_message() is that it makes it impossible
to use whitespace formatting as it drops \n and \t and leading spaces
and compresses inline multiple spaces. But maybe that is good, as doing
that will not work well with dynamic-width fonts, ie it makes GUI output
ugly between lines, and tables should go to fprintf(stdout,..).
It saves more work later to get this right the first time 
and kills
motivation on all sides to have to revert changes later 
Hamish
What a mess. But not at all surprising after over 20 years of volunteer
programming by umteem people.
I fully support the standardization of error messages. The suggestions all
look good to me.
There is considerable back and forth (thoughtful) about periods. For easy
consistency, I'd simply go with: sentence ends with period; phrase does not
end with period. (and as HB says sentence != phrase). Save ellipses for
pending operations (Reading...).
Looking this over didn't take much time and I recommend everyone follow
Hamish's suggestion so we can move ahead with this.
We'll need to do the same thing with the GUI, especially as we add more
error traps and error message boxes. But let's do the main C modules first
and then use these specs as guidance.
Michael
On 6/10/07 11:02 PM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Carlos Dávila wrote:
I'm new in dev list, but I've been working in translations for some
time. I would like to standardize some grass messages, according to
what is proposed in
http://grass.gdf-hannover.de/wiki/Development_Specs (please check
last changes) in order to ease the work for translators and get a
more consistent program. I don't know if standard messages proposed in
wiki can already be used or if discussion is still open. Any feedback
is welcome. If no objections are reported, I will start changing
messages in the next days, at least the most obvious.The ideas on the wiki page are just the opinions of a few of us who
edited the page AFAICT, not a full consensus reached on the -dev mailing
list which it needs to be before any mass change. So that it can be
formalized and the discussion closed, I too would ask everyone to review
what's listed there, and discuss here. There are several unresolved
questions there which need to be answered.At least I hope with g.message and G_*message() we have all the tools we
need now? My only gripe with G_message() is that it makes it impossible
to use whitespace formatting as it drops \n and \t and leading spaces
and compresses inline multiple spaces. But maybe that is good, as doing
that will not work well with dynamic-width fonts, ie it makes GUI output
ugly between lines, and tables should go to fprintf(stdout,..).It saves more work later to get this right the first time
and kills
motivation on all sides to have to revert changes laterHamish
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Michael Barton wrote:
There is considerable back and forth (thoughtful) about periods. For
easy consistency, I'd simply go with: sentence ends with period;
phrase does not end with period. (and as HB says sentence != phrase).
Save ellipses for pending operations (Reading...).
Standardization by place: module descriptions should be sentence-like
and end with periods (consistently), option and flag descriptions are
mostly phrase-like and don't end with punctuation.
e.g.
- the file tools/module_synopsis.sh makes looks weird if 1/4 of the
modules' descriptions don't end with a dot.
- as Carlos just noticed, the tcl GUI appends ":" after the option
descriptions, and punctuation before that looks bad. If the option
description is multi-sentence and it looks odd in the help page for the
last sentence not to end with a period, while the first one does, the
solution is to split the string up into short ->label and tooltip
->description parts.
I am unsure if all G_fatal_error(), G_warning(), and G_message() should
have "." or not. IMHO things like "Operation complete" and "Done" on a
line by themselves look stronger as a punctuated statement, but others
may disagree.
We can agree that the first letter of all messages should be capitalized?
Hamish
more questions to answer before we go much further....
We need to sort out parentheticals before we go much further as well:
just because something is a variable doesn't mean it sould be in
brackets, especially if it is an integral part of the sentence
structure.
To me this is way too overformatted and difficult to read:
(v.to.db/report.c)
Updating database ...
100%
[2] categories read from map
[0] records selected from table
[0] categories read from map exist in selection from table
[1] categories read from map don't exist in selection from table
[1] records updated/inserted
[0] update/insert errors
Current attribute table links:
Vector map <roads_5m> is connected by:
layer <1> table <roads_5m> in database </home/hamish/grassdata/spearfish60/user1/dbf/> through driver <dbf> with key <cat>
<mapname> is ok, but <1>, [0], <cat> makes it too broken up IMO.
Perhaps " with key 'cat' " might be nicer?
also:
G63> g.list vect
<vector> files available in mapset <PERMANENT>:
"vector" does not need to be in <>. Maybe if we could do syntax
highlighting in the GUI this wouldn't look so bad, but as plain
text it just doesn't work for me with the extra chars.
From the wiki page:
How should Errors/Warnings/Messages be formatted
* strings < >
o e.g. Raster map <%s> not found
* numbers
o e.g. Line [%d] deleted
? The [bracketed] parenthetical disrupts the flow of the phrase and
doesn't help enhance clarity of meaning. IMHO, this reads better without
brackets: "Line %d deleted." Brackets should be used when value is
outside of the phrase: "Unknown line [%d]". --HB
?,
Hamish
Module descriptions are a different sort of beast from error messages--and
from GUI messages and other descriptors. All need standardization, but I'd
recommend doing them one at a time so as not to overwhelm everyone.
If we can standardize error messages first it might be the simplest piece to
attack. Then move on to others like module descriptions in the module code,
module doc formatting, GUI, etc.
Michael
On 6/13/07 2:36 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Michael Barton wrote:
There is considerable back and forth (thoughtful) about periods. For
easy consistency, I'd simply go with: sentence ends with period;
phrase does not end with period. (and as HB says sentence != phrase).
Save ellipses for pending operations (Reading...).Standardization by place: module descriptions should be sentence-like
and end with periods (consistently), option and flag descriptions are
mostly phrase-like and don't end with punctuation.e.g.
- the file tools/module_synopsis.sh makes looks weird if 1/4 of the
modules' descriptions don't end with a dot.- as Carlos just noticed, the tcl GUI appends ":" after the option
descriptions, and punctuation before that looks bad. If the option
description is multi-sentence and it looks odd in the help page for the
last sentence not to end with a period, while the first one does, the
solution is to split the string up into short ->label and tooltip
->description parts.I am unsure if all G_fatal_error(), G_warning(), and G_message() should
have "." or not. IMHO things like "Operation complete" and "Done" on a
line by themselves look stronger as a punctuated statement, but others
may disagree.We can agree that the first letter of all messages should be capitalized?
Hamish
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
I agree. In fact, for this particular example, I don't think that or <>
add anything at all--even to map names. Single quotes would be better for
map names and variable names. I'd also remove an extraneous colon after "by"
and add the word "to" after the layer (see below). A bit of white space
wouldn't hurt.
Michael
On 6/13/07 4:11 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:
more questions to answer before we go much further....
We need to sort out parentheticals before we go much further as well:
just because something is a variable doesn't mean it sould be in
brackets, especially if it is an integral part of the sentence
structure.To me this is way too overformatted and difficult to read:
### suggested reformatting ###
### changes include: removing all around counts, removing colon following
### "by", adding "to" following "1", replacing <> with '', adding "." at
### end.
(v.to.db/report.c)
Updating database ...
100%
2 categories read from map
0 records selected from table
0 categories read from map exist in selection from table
1 categories read from map don't exist in selection from table
1 records updated/inserted
0 update/insert errors
Current attribute table links:
Vector map 'roads_5m' is connected by layer 1 to table 'roads_5m' in
database '/home/hamish/grassdata/spearfish60/user1/dbf/' through driver
'dbf' with key 'cat'.
<mapname> is ok, but <1>, [0], <cat> makes it too broken up IMO.
Perhaps " with key 'cat' " might be nicer?
also:
G63> g.list vect
<vector> files available in mapset <PERMANENT>:"vector" does not need to be in <>. Maybe if we could do syntax
highlighting in the GUI this wouldn't look so bad, but as plain
text it just doesn't work for me with the extra chars.From the wiki page:
How should Errors/Warnings/Messages be formatted* strings < >
o e.g. Raster map <%s> not found
* numbers
o e.g. Line [%d] deleted? The [bracketed] parenthetical disrupts the flow of the phrase and
doesn't help enhance clarity of meaning. IMHO, this reads better without
brackets: "Line %d deleted." Brackets should be used when value is
outside of the phrase: "Unknown line [%d]". --HB?,
Hamish
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton
Hamish escribió:
Carlos Dávila wrote:
I'm new in dev list, but I've been working in translations for some
time. I would like to standardize some grass messages, according to
what is proposed in
http://grass.gdf-hannover.de/wiki/Development_Specs (please check
last changes) in order to ease the work for translators and get a more consistent program. I don't know if standard messages proposed in
wiki can already be used or if discussion is still open. Any feedback
is welcome. If no objections are reported, I will start changing
messages in the next days, at least the most obvious.
The ideas on the wiki page are just the opinions of a few of us who
edited the page AFAICT, not a full consensus reached on the -dev mailing
list which it needs to be before any mass change. So that it can be
formalized and the discussion closed, I too would ask everyone to review
what's listed there, and discuss here. There are several unresolved
questions there which need to be answered.At least I hope with g.message and G_*message() we have all the tools we
need now? My only gripe with G_message() is that it makes it impossible
to use whitespace formatting as it drops \n and \t and leading spaces
and compresses inline multiple spaces. But maybe that is good, as doing
that will not work well with dynamic-width fonts, ie it makes GUI output
ugly between lines, and tables should go to fprintf(stdout,..).It saves more work later to get this right the first time
motivation on all sides to have to revert changes laterHamish
As I continue translating I find a lot messages that are affected by what is being discussed in this topic and it's a bit frustrating. I can leave messages untranslated, and so I will have to go back to them later, or I can translate them in the way proposed, with the risk of having to change them later if proposal are changed, while it would be easy for me to change messages in the moment if any agreement is reached.
I would like to reduce this situation if possible, so I propose to split discussion by items listed in wiki and try to get an agreement at least in those easier. We could add votes under each item in wiki and finally take a decision and mark item as accepted.
E.g.:
* First letter should be capitalized
+1 Carlos
* Use the present tense (cannot instead of could not; *better: unable to*)
+1 Carlos
and so on
What do you think about this?
Carlos
Michael Barton wrote:
Module descriptions are a different sort of beast from error
messages--and from GUI messages and other descriptors. All need
standardization, but I'd recommend doing them one at a time so as not
to overwhelm everyone.If we can standardize error messages first it might be the simplest
piece to attack. Then move on to others like module descriptions in
the module code, module doc formatting, GUI, etc.
I would consider module and option/flag descriptions much easier "low-
hanging fruit" than error messages. For them the rules are simpler,
- module descriptions end with a "."
- option/flag descriptions do not.
- Multi-sentence descriptions are probably good candidates to break up
into a short ->label + a ->description to hold additional info.
- Begin with a capital letter.
- Don't pad whitespace.
For standard error/warning messages (ie the ones that always come right
after G_open_file() or whatever) we can pick something nice and specify
that on the wiki page to avoid repetitious translations of almost
identical messages.
For the vast majority of error/warning/regular messages, they are
single-use, module dependant, and maybe put there by the programmer on a
just-in-case basis, ie they may never be seen by a user. Contrast that
with the module description and option descriptions which have high
exposure, & thus greater result from a translator's time.
library translations have high-reuse value.
GUI translations have high-exposure value.
2c,
Hamish
2007/6/18, Hamish <hamish_nospam@yahoo.com>:
library translations have high-reuse value.
GUI translations have high-exposure value.
This is the main reason why I decided to sprint on the gui messages.
New users are much more likely put off by non native language in GUI
than current/old users, which already used to CLI modules in english.
--
PMarc:
Debian, GIS, gpsd, OpenWRT user and wannabe-devel
Lives @ -22.915 -42.224
Hamish escribió:
Michael Barton wrote:
Module descriptions are a different sort of beast from error
messages--and from GUI messages and other descriptors. All need
standardization, but I'd recommend doing them one at a time so as not
to overwhelm everyone.If we can standardize error messages first it might be the simplest
piece to attack. Then move on to others like module descriptions in
the module code, module doc formatting, GUI, etc.
I would consider module and option/flag descriptions much easier "low-
hanging fruit" than error messages. For them the rules are simpler,- module descriptions end with a "."
- option/flag descriptions do not.
- Multi-sentence descriptions are probably good candidates to break up
into a short ->label + a ->description to hold additional info.
- Begin with a capital letter.
- Don't pad whitespace.For standard error/warning messages (ie the ones that always come right
after G_open_file() or whatever) we can pick something nice and specify
that on the wiki page to avoid repetitious translations of almost
identical messages.For the vast majority of error/warning/regular messages, they are
single-use, module dependant, and maybe put there by the programmer on a
just-in-case basis, ie they may never be seen by a user. Contrast that
with the module description and option descriptions which have high
exposure, & thus greater result from a translator's time.library translations have high-reuse value.
GUI translations have high-exposure value.2c,
Hamish
Another issue to discuss: module descriptions currently have verbs both in infinitive and present, depending on the module. We should choose only one tense, infinitive IMHO.
Carlos
Paulo Marcondes escribió:
2007/6/18, Carlos Dávila <cdavilam@jemila.jazztel.es>:
Another issue to discuss: module descriptions currently have verbs both
in infinitive and present, depending on the module. We should choose
only one tense, infinitive IMHO.+1
Shall I point the utility of a wikipage for all these musings?
Carlos, as you are doing all the asking, could you sum it all up on a page?
That should help other translators too.
They are already here:
http://grass.gdf-hannover.de/wiki/Development_Specs
You have my support for all of this.
Michael
On 6/18/07 3:10 AM, "Hamish" <hamish_nospam@yahoo.com> wrote:
Michael Barton wrote:
Module descriptions are a different sort of beast from error
messages--and from GUI messages and other descriptors. All need
standardization, but I'd recommend doing them one at a time so as not
to overwhelm everyone.If we can standardize error messages first it might be the simplest
piece to attack. Then move on to others like module descriptions in
the module code, module doc formatting, GUI, etc.I would consider module and option/flag descriptions much easier "low-
hanging fruit" than error messages. For them the rules are simpler,- module descriptions end with a "."
- option/flag descriptions do not.
- Multi-sentence descriptions are probably good candidates to break up
into a short ->label + a ->description to hold additional info.
- Begin with a capital letter.
- Don't pad whitespace.For standard error/warning messages (ie the ones that always come right
after G_open_file() or whatever) we can pick something nice and specify
that on the wiki page to avoid repetitious translations of almost
identical messages.For the vast majority of error/warning/regular messages, they are
single-use, module dependant, and maybe put there by the programmer on a
just-in-case basis, ie they may never be seen by a user. Contrast that
with the module description and option descriptions which have high
exposure, & thus greater result from a translator's time.library translations have high-reuse value.
GUI translations have high-exposure value.2c,
Hamish
__________________________________________
Michael Barton, Professor of Anthropology
School of Human Evolution & Social Change
Center for Social Dynamics & Complexity
Arizona State University
phone: 480-965-6213
fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton