What you and Mark are pointing to (and I quite agree) is that strings have very specific roles.
But that doesn't mean these roles don't occur in different places. Dialog yes/no is a great example. You really want most dialogs to all say it the same way, whether it's "yes" or "no", or "OK" vs "Cancel". That doesn't mean you ever want to use that one for ANY other purpose! So the text we're talking about being suitable here, would be limited to very specific items, playing a standardized role. "OK" and "Cancel". The names of the sound streams. The names of the standard "hard" buttons. These would all need to be carefully documented as part of the UI standard, covering not just the resource name to use, but also the expected UI role. But this is really no different than within any single app. The same principle applies -- you can get in trouble if you try to use the same localized string for two different purposes, just because they happen to be the same in English. But, in the absence of a carefully thought out approach here, we're better off just copying. On Jan 22, 7:28 pm, Dianne Hackborn <hack...@android.com> wrote: > 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 <mmur...@commonsware.com>wrote: > > > > > > > > > > > On Sat, Jan 22, 2011 at 5:18 PM, Bob Kerns <r...@acm.org> 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/smand1andhttp://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 android-developers@googlegroups.com > > To unsubscribe from this group, send email to > > android-developers+unsubscr...@googlegroups.com<android-developers%2Bunsubs > > cr...@googlegroups.com> > > For more options, visit this group at > >http://groups.google.com/group/android-developers?hl=en > > -- > Dianne Hackborn > Android framework engineer > hack...@android.com > > 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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
