Re: Localising "dynamic" string resources in code
Re: Localising "dynamic" string resources in code
- Subject: Re: Localising "dynamic" string resources in code
- From: "Gary L. Wade" <email@hidden>
- Date: Wed, 10 Oct 2012 12:01:28 -0700
- Thread-topic: Localising "dynamic" string resources in code
A better approach when using NSLocalizedString and its variants is to
always use a highly non-user-friendly string for the key that matches the
definitive meaning behind the particular string.
One benefit is that when you see that string in your UI, you know you
don't have a translated string for that key, and the problem is squarely
within your strings files.
Another benefit is for those cases where you really may want the same
string in your development language (e.g., English) but at least one other
language may need a very different string.
Another benefit is that you use the strings files for what they were meant
for, an encapsulation of human-readable textual resources rather than
hard-coding something within your software.
An example from a project I once worked on where the same string may be
used in the development language but differ in other languages is the
string "State". In US English, this word refers to a governmental body.
It also means the current condition of some variable. To change either
string to be more descriptive would be overkill: "State of your
Residence/Vote/Used To Live" and "State of that Variable". In UK English,
we wanted "County" in place of the governmental body and "State" for the
variable condition.
By using keys similar to these instead, we solved the collision issue and
utilized the string files and source code for what they were meant to be:
"--placeForCity" and "--stateOfVariable". And, if we ever saw those, we
knew immediately we were in trouble.
Also, you should always use named constant variables in your code rather
than hard-coding these keys; this will save you from those cases where you
want the same key but misspell it in one of the places used.
Also, you should look at using APPKIT_EXTERN when defining your named
constants in headers (allowing the key to be used across source files),
since it can be useful in those cases where you may be needing to do
Objective-C++ and Objective-C in the same project. Again, the benefit
here is encapsulation: if you want to change the spelling of the key, you
have its spelling in one place only (other than the key itself in the
strings file) rather than in many different places and possibly missing
one.
--
Gary L. Wade
http://www.garywade.com/
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden