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

Reply via email to