[android-developers] Re: Using internal Android string resources
I actually had this very conversation with my (bilingual) wife the other day. Another potential problem with using system strings in your own project is that if your default language is English and a user has their phone set for a language you don't support, they'll then see English for all your strings, but all the buttons and what not will be in their language. This happens sometimes in localized software. My wife's opinion was that even if the user doesn't speak English well, they will already know the Yes/No/OK/Cancel buttons. But if they do speak English well, they'd rather see the app all in English or all in their language, not some messy hybrid. It makes the app feel unfinished. One neat tool for dealing with the common translations is http://crowdin.net/ which will suggest translations from it's own database of previously translated strings. -Kevin On Jan 22, 7:48 am, DanH danhi...@ieee.org wrote: Yeah, while TPTB have a legitimate reason to object to using any/all of the system translations willy-nilly, it seems like it would be simple and very useful to harden a set of the most common stuff -- yes/no, continue/cancel, etc. Minimal effort on the part of TPTB -- just commit to never deleting those words. On Jan 22, 1:32 am, Brill Pappin br...@pappin.ca wrote: Yes, and I think thats a good strategy for graphics. However there are thousands of string in different language value resources... which is why I say it it would save a heck of a lot of time. IMO it's worth having to test with each new platform. - Brill Pappin -- 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
[android-developers] Re: Using internal Android string resources
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.comwrote: 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.comandroid-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
[android-developers] Re: Using internal Android string resources
Actually, you can't have it both ways *AT THE SAME TIME*. Having platform-defined strings only make sense for platform-defined things. Like platform-defined widgets, where you can have platform- defined constants for the platform-defined default values. The roles have to be tightly defined to have any benefit. Or platform-defined names for platform-defined things, like the audio streams, or other hardware bits and pieces, like camera, headphone, etc. Maybe a few key concepts, like Account, referring specifically to the account manager concept. If Android phones had important buttons with text labels, you'd want to capture that label as a resource, and localize that to the hardware! All the rest -- you manage yourself. On Jan 22, 2:34 pm, Brill Pappin br...@pappin.ca wrote: There is that problem Bob, but you can't have it both ways. Ether you depend on standards and consistency from the platform itself or you manage it yourself. Most advice regarding resources are to manage them yourself (your argument applies to images as well as strings). so that your not surprised when something changes or goes missing. I think there is legitimacy to both ideologies. For the moment I don't have a lot of confidence in the ability of Goole not to keep the platform from fragmenting even further, so I'm going to do with the locale resource model. It's somewhat mute anyway, because most of those already translated string resources are hidden from the public API. Ther is no choice but to extract them. - Brill Pappin -- 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
Re: [android-developers] Re: Using internal Android string resources
You might try out http://www.icanlocalize.com/. I've used their paid service to translate an app, but it's free to set up an account, and then they have a web-based tool for managing translations that's quite similar to what you're describing. They apparently don't mind you using their tool to manage your own translations. Anyway, take a look before you build your own. String -- 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
Re: [android-developers] Re: Using internal Android string resources
Nice. There are times I could certainly use a service like that! What I was thinking though is something a bit more dynamic, so you could build resource collections out of what was stored in the database and/or contribute more translations. License them under the Apache License so you can use them in your Android apps etc. We'll see if it actually gets built :) It all a matter of the time I don't have. - Brill Pappin On 2011-01-23, at 3:24 AM, String wrote: You might try out http://www.icanlocalize.com/. I've used their paid service to translate an app, but it's free to set up an account, and then they have a web-based tool for managing translations that's quite similar to what you're describing. They apparently don't mind you using their tool to manage your own translations. Anyway, take a look before you build your own. String -- 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 -- 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
Re: [android-developers] Re: Using internal Android string resources
On Sat, Jan 22, 2011 at 2:32 AM, Brill Pappin br...@pappin.ca wrote: However there are thousands of string in different language value resources... which is why I say it it would save a heck of a lot of time. Write yourself a script that copies the string resource element from the platform resources into your own project's copy of the resources. Not only will writing that script take less time than will the testing, but you are presuming that device manufacturers don't change the strings, and I doubt that's a safe assumption. -- Mark Murphy (a Commons Guy) http://commonsware.com | http://github.com/commonsguy http://commonsware.com/blog | http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.9 Available! -- 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
[android-developers] Re: Using internal Android string resources
Yeah, while TPTB have a legitimate reason to object to using any/all of the system translations willy-nilly, it seems like it would be simple and very useful to harden a set of the most common stuff -- yes/no, continue/cancel, etc. Minimal effort on the part of TPTB -- just commit to never deleting those words. On Jan 22, 1:32 am, Brill Pappin br...@pappin.ca wrote: Yes, and I think thats a good strategy for graphics. However there are thousands of string in different language value resources... which is why I say it it would save a heck of a lot of time. IMO it's worth having to test with each new platform. - Brill Pappin -- 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
Re: [android-developers] Re: Using internal Android string resources
Thats a good idea. I've been meaning to build a tool that can manage them for me as well, but its one of those things that I never get to :) Maybe its time now. - Brill Pappin -- 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
[android-developers] Re: Using internal Android string resources
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. On Jan 22, 4:18 am, Mark Murphy mmur...@commonsware.com wrote: On Sat, Jan 22, 2011 at 2:32 AM, Brill Pappin br...@pappin.ca wrote: However there are thousands of string in different language value resources... which is why I say it it would save a heck of a lot of time. Write yourself a script that copies the string resource element from the platform resources into your own project's copy of the resources. Not only will writing that script take less time than will the testing, but you are presuming that device manufacturers don't change the strings, and I doubt that's a safe assumption. -- Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy _The Busy Coder's Guide to *Advanced* Android Development_ Version 1.9 Available! -- 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
[android-developers] Re: Using internal Android string resources
There is that problem Bob, but you can't have it both ways. Ether you depend on standards and consistency from the platform itself or you manage it yourself. Most advice regarding resources are to manage them yourself (your argument applies to images as well as strings). so that your not surprised when something changes or goes missing. I think there is legitimacy to both ideologies. For the moment I don't have a lot of confidence in the ability of Goole not to keep the platform from fragmenting even further, so I'm going to do with the locale resource model. It's somewhat mute anyway, because most of those already translated string resources are hidden from the public API. Ther is no choice but to extract them. - Brill Pappin -- 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
Re: [android-developers] Re: Using internal Android string resources
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/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 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
[android-developers] Re: Using internal Android string resources
I guess I don't uderstand what the issue is here. The public android.R.strings package is tiny, with 22 entries, only 7-8 of which are general purpose to the point where they are usable in an average app.I am not sure how the other localized strings could even concievably be used without first copying them into your own resources. Perhaphs by hard coding the resource ID values would work, but that seems extremely fragile and sure to break with every release of the platform. On Jan 23, 7:45 am, 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/commonsguyhttp://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 For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
Re: [android-developers] Re: Using internal Android string resources
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.comwrote: 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/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 android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.comandroid-developers%2bunsubscr...@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
Re: [android-developers] Re: Using internal Android string resources
Oh i understand the problem and potential issues, like calling a car a Nova in Mexico :) I've been meaning to write myself a tool though that would allow me to construct a database of string and generate property files from them in multiple languages. It won't always work (particularly with string that have replaceable variables) but your dialog_positive_button_label is a good example of ones that will work. Actually if I made the tool open to others, I might get some help with people that are fluent in other languages helping to maintain it. Based on the recent exploration of the Android OS source, I suspect that the Google team (your team?) actually does have some sort of database like that... some of the translations may even have been run through the translator to generate them. Anyway, i'f I actually get around to building it, I'll let people know :) - Brill Pappin -- 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
[android-developers] Re: Using internal Android string resources
Yes, and I think thats a good strategy for graphics. However there are thousands of string in different language value resources... which is why I say it it would save a heck of a lot of time. IMO it's worth having to test with each new platform. - Brill Pappin -- 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
