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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
15 matches
Mail list logo
