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