Hello,
I am from I18n team. Please see inline for my comments.
Doug Hellmann wrote on 11/3/2016 2:19 AM:
Excerpts from Brian Rosmaita's message of 2016-11-02 16:34:45 +0000:
This issue came up during a code review; I've asked around a bit but
haven't been able to find an answer.
Some of the help output for utility scripts associated with Glance aren't
being translated, so Li Wei put up a patch to fix this [0], but there are
at least two problematic cases.
Case 1:
parser.add_option('-S', '--os_auth_strategy', dest="os_auth_strategy",
metavar="STRATEGY",
help=_("Authentication strategy (keystone or noauth)."))
For that one, 'keystone' and 'noauth' are identifiers, so we don't want
them translated. Would putting single quotes around them like this be
sufficient to indicate they shouldn't be translated? For example,
help=_("Authentication strategy ('keystone' or 'noauth').")
Andreas Jaeger mentioned that maybe we could use a "translation comment"
[1]. I guess we'd do something like:
# NOTE: do not translate the stuff in single quotes
help=_("Authentication strategy ('keystone' or 'noauth').")
The ability to pass comments to the translators like that seems
really useful, if it would work with our tools.
+1 from me and also Daisy (former i18n PTL).
I18n team quite agrees what adding translation comments can pass more
information to translators from developers.
It seems like things we put in quotes should not be translated, by
convention.
I agree with Doug, and Brant's suggestion also looks nice.
To slightly revise from Brant's suggestion, the following original
string for translation looks much better:
: "Authentication strategy (%(keystone)s or %(noauth)s).")
-> %(keystone)s and %(noauth)s will be replaced with "'keystone'" and
"'noauth'" correspondingly.
What are other people doing for this?
Case 2:
We've got a big block of usage text, roughly
usage = _("""
%prog <command> [options] [args]
Commands:
keyword1 what it does
keyword2 what it does
...
keyword8 what it does
""")
We don't want the keywords to be translated, but I'm not sure how to
convey this to the translators.
This is a case where using quotes won't work. Using a different
tool to build the help text (argparse instead of optparse), or even
just building the text from parts inline (put the parts you do or
do not want translated into separate variables and then combine the
results like a template) might work. Both add a bit of complexity.
The second option doesn't require completely rewriting the CLI
processing logic.
I think translators easily capture the context of this kind of command
help strings.
After my brief research on other projects, GNU coreutils also do the
same way for extracting translation strings
(e.g., http://git.savannah.gnu.org/cgit/coreutils.git/tree/src/ls.c#n4882 ).
For command help strings, translators will prefer not to divide one
overall string into multiple line-by-line strings,
for example: _("""%prog <command> [options] [args]""") + "\n" +
_("""Commands:""") + "\n" + _(""" keyword1 what it does""") .
By the way, can i18n team set any rules within the team,
for example, "don't translate any words in capital.", "If developers
don't want to translate some words, write them in capital.", and so on?
What do developers think about this idea?
With many thanks,
/Ian
Thanks in advance for your help,
brian
[0] https://review.openstack.org/#/c/367795/8
[1] http://babel.pocoo.org/en/latest/messages.html#translator-comments
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
