Marking strings for translation

[Brian J. Tarricone]

On 08/25/04 20:59, Jasper Huijsmans wrote:
> Hey all,
> 
> I have been updating the Dutch translations and there were a few things 
> I'd like to mention. These are of course opinions, not objective truths.
> 
> 1. Can we try to avoid putting markup in translations? E.g., 
> <b>Workspace</b> and <i>Workspace</i> are not really different ...

true, that's annoying.  what would you suggest doing in place of it?  i
suppose for functions that support a printf-style thing, you can do:
..., "<b>%s</b>", _("Workspace"), ...
but for other cases it might not be so easy.  doing 3 strlcat() calls seems
like a bit much (esp in cases where speed matters) just to make it a little
easier on translators (mind you, i don't want to make the translators' lives
difficult, but i think a copy/paste needed by a translator is much less
important than taking a performance hit).

> 2. When a translator has to use copy/paste a lot, there may be room for 
> improvement. E.g, in the shortcut editor: Move to workspace 1, Move to 
> workspace 2, Move to ... ;-)

again, same deal - it seems kinda silly (from a programmingg standpoint) to
do a loop of snprintf() calls when a few static strings will suffice.

> 3. Using too short sentences are hard to translate without context. For 
> instance "printing", I think either that string should be expanded, or a 
> comment added above the statement, so that is will show up in the po file.

this is kinda problematic.  to extend your example, say we have a dialog that
gives the user feedback that the app is sending data to the printer.  the
dialog says "Printing...", and that's it.  it's awkward and overkill to have
more than that.  you just want something simple, not something like,
"Sending document to printer...".  while that doesn't seem like a long
statement, it requires much more time to comprehend from a user standpoint than
a simple one-word message.

> 4. We're doing pretty well here, but for technical terms and format 
> strings a comment explaining the context can be very useful.

good idea - i know i can be pretty bad about commenting my code.

> 5. Consistent use of semicolon, question mark, exclamation mark. 
> Sometimes we add a space, sometimes we don't. Probably we should not add 
> the space, that's how it's done in normal English texts (corret me if 
> I'm wrong). Exclamation marks should probably never be used (no shouting).

yes, this is a bit of a pet peeve of mine.  translators, feel free to use
whatever convention is common for your language/country, but for the raw
english, there should be NO spacing between sentences and punctuation.  the
only exception is the dash character when used as an emdash (that is, not as a
hyphen), in which case you have a space before and after the dash.

with regard to style, exclamation points should indeed be avoided where
possible.  also, aside from the ellipsis (...), punctuation marks should never
be repeated.  one question mark only, please.

> 6. Consistent terminology, this is hard and I'm often quite uncertain 
> about the right words to use. E.g., options, settings, preferences, 
> properties.

that's a fun one.  the only real disctinction i can make is that "properties"
are generally an object-oriented concept.  properties are associated with a
particular object.  say, for a video file, the properties might include the
video and audio codecs, bitrate, frame size, etc.  for a file, your
properties might be permissions, size, owners, mtimes, etc.

for the other three, i tend to see "preferences" as a more user-centric word,
as in "what would the user _prefer_ to do?"  whereas an "option" is more
like "user, these are the options i am giving you".  "settings" is perhaps
somewhere in the middle, but more like "options".  i think in this case, the
choice between the three is mainly stylistic, but we should try to be consistent
across xfce if possible.  (personally, i prefer "settings" most of the time,
and occasionally "preferences".  i'm not a big fan of "options".)

> Ok, well, it's nothing really big, just something to think about every 
> once in a while. Better not go and change too many strings now anyway, 
> because of the freeze. I just thought I'd write it now, before I forget 
> again.

blah, the string freeze, i forgot.  oh well... i hope they're ok.  if not,
it'll wait until alpha2 or beta.

	-brian