Translations are *very* dependent on the semantics they are used in. Also, you can't really know what translations there will be -- some devices ship with only English and Spanish, some with EFIGS, some with the full set of current translations, some other things.
The word-smithing of strings also tends to vary. For example, indeed the "yes" and "no" strings actually say "OK" and "Cancel", because these are the strings used in alert dialog buttons. At the time they were written, these were just the positive and negative choices; as UI design and word-smithing proceeded, they became the text they have now. And unfortunately because they are the strings you see in the UI are those, if someone decides that they'd like to have different text for the dialogs then the strings will change on you. So these really should not have been exposed in the public API. Or if they are, it should have been under a very specific name such as "dialog_positive_button_label". You'll see that situation a lot in strings -- sure there is this fine string in the platform, but it is being used for a very specific thing, and the text can change over time depending on how one wants to present that thing in the UI. Unless you are showing a string for the exact same purpose, you don't want to use the one in the platform. If we were to define a more generic set of strings for apps to use, we wouldn't want to use them in the platform because each string we translate needs to be for a single specific place, to allow translations to be phrased or adjusted correctly. Thus applications relying on these strings would be relying on a questionable translation that hasn't been validated in the UI in the specific context it is used in. I think it's better to just look at the strings in the open-source platform as a resource you can draw from to incorporate into your app, not as an API for the application to use. And keep in mind that the vast majority of strings are actually in the applications, not in the framework itself. On Sat, Jan 22, 2011 at 3:45 PM, Mark Murphy <[email protected]>wrote: > On Sat, Jan 22, 2011 at 5:18 PM, Bob Kerns <[email protected]> wrote: > > While I (strongly) agree with this advice -- there is a major > > downside. If you copy it into your application, and the platform > > changes (an update, a manufacturer customization, etc.), then your > > application's look-and-feel (including terminology) will vary from the > > platform standard. And, in the case up upgrades, older apps will vary > > from newer ones. The result is the user experience is less cohesive. > > FWIW, Google's recommendation is to aim for internal consistency > first, then platform fidelity. > > Strings are particularly pernicious. For example, I seem to recall > that the platform definition of the "yes" string is "Set", due to some > screwball decision. If OEMs do that, then your app may be flat out > wrong on some devices, with incorrect prompts, messages, or whatever > the strings are used for. > > -- > Mark Murphy (a Commons Guy) > http://commonsware.com | http://github.com/commonsguy > http://commonsware.com/blog | http://twitter.com/commonsguy > > Android Training in London: http://bit.ly/smand1 and http://bit.ly/smand2 > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected]<android-developers%[email protected]> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
