On 3/18/2010 8:04 AM, Derek Atkins wrote:
Jeff Kletsky<gnuc...@allycomm.com> writes:
So then when I submit a patch for things like src/business/business-utils/
business-utils.scm -- the existing usages of (N_ "some string") probably
should be converted to (_ "some string") -- correct? I was puzzled by that as,
at least as I understand it, in C N_(string) is a noop marker and _() is the
gettext () call.
N_ is a noop marker in both C and Scheme
_ is the gettext call in both C and Scheme
Where you place the paren is based on the language.
(define gnc:*business-label* (N_ "Business"))
(define gnc:*company-name* (N_ "Company Name"))
(define gnc:*company-addy* (N_ "Company Address"))
(define gnc:*company-id* (N_ "Company ID"))
(define gnc:*company-phone* (N_ "Company Phone Number"))
(define gnc:*company-fax* (N_ "Company Fax Number"))
(define gnc:*company-url* (N_ "Company Website URL"))
(define gnc:*company-email* (N_ "Company Email Address"))
(define gnc:*company-contact* (N_ "Company Contact Person"))
These are fine here because these string constants are defined in
Scheme. This would be a no-op, so it would mark these strings
are translatable but wouldn't translate them immediately. This
is important if you want to use them as a key to a database entry (which
should always use the untranslated string) but also put it in the UI
(which should always use the translated string).
(export gnc:*business-label* gnc:*company-name* gnc:*company-addy*
gnc:*company-id*
gnc:*company-phone* gnc:*company-fax* gnc:*company-url*
gnc:*company-email* gnc:*company-contact*)
(define gnc:*option-section-accounts* (_ OPTION-SECTION-ACCOUNTS))
(define gnc:*option-name-trading-accounts* (_ OPTION-NAME-TRADING-ACCOUNTS))
(export gnc:*option-section-accounts* gnc:*option-name-trading-accounts*)
(define gnc:*option-section-budgeting* (_ OPTION-SECTION-BUDGETING))
(define gnc:*option-name-default-budget* (_ OPTION-NAME-DEFAULT-BUDGET))
(export gnc:*option-section-budgeting* gnc:*option-name-default-budget*)
These calls would define these options as the translated versions of
these strings. I'm not sure this is correct. So long as the OPTION
strings are defined as N_ in the C code you don't need to translate them
here unless you ONLY want access to the translated version of the
string.
-derek
Ah, I didn't realize that the translation was being handled
transparently in the rendering layer. It was really bothering me that
the KVP keys seemed to be language-dependent. Looking at
src/gnome-utils/dialog-options.c a little more carefully I now see
constructs like _(*raw), _(label), and _(description) sprinkled in there.
Thanks to all for helping me through my first shot at Gnu-style i18n.
Jeff
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
