As someone who's been involved with internationalization of software
for over 25 years -- while I'm certainly glad you provide this syntax,
I think signalling an error is just a bit over the top. A warning
would be sufficient.
Here's why: In my experience (perhaps not comprehensive), the workflow
goes like this: A developer writes the message, in his language of
choice, usually English, but perhaps, say, Japanese, and plops in %s
and friends where appropriate, and arranges the arguments to the
formatting code in the same order as they occur in his format string.
Then someone comes along and whacks him over the head for not
externalizing it for translation, and it is moved to strings.xml or
other localization resource.
Finally, maybe one time in 100, the application is successful enough
to be localized to other languages. One might wish for this to be more
often, but actually I think I'm being generous here. But it's a pain
to do if the previous step hasn't been done, as a matter of practice.
So we'd like to make that as easy as possible. Really, I don't think
we're even close to making it as easy as we should make it! Especially
since the programmer, and likely his manager as well, will correctly
perceive that the effort stands a high probability of being wasted.
Then finally, if we're lucky, we get to translate the app. If we're
really, really lucky, we'll have a QA department that will try to
reproduce as many of the messages as possible, in the original
language.
Now, off goes string.xml and friends to the localization service,
translator, team member, or maybe the developer's wife. Much of the
time, maybe 80% or more, the strings with multiple %s's will not be
using them in a way that is particularly sensitive to language. They
may be constructing an identifier name, or a list, or may occur in
different sentences, which would not in most cases require reordering.
Your mileage may vary on the frequency, of course. But I'd say the
most common use would be something like "%d cats and %d dogs" -- and
ordering is not the problem you face here, but rather, handling of
plurals.
And you get big kudos for addressing it. I hadn't noticed until now
that <plurals/is documented. I don't know if I'd missed seeing it, or
it's a recent addition to the documentation, but thank you! But "%d
gatos y %d perros" or "%d猫と%d犬?" are perfectly fine, from an ordering
standpoint.
BUT! Your Spanish translator is barfing right now, and it has nothing
to do with positionals. The programmer didn't think about plurals.
(yeah, yeah, he should have. See above for the unfortunate reality).
Your translator has to get the programmer to change the code. Bletch.
That likely requires a whole new release. more expensive QA, etc.
Yikes! Maybe we live with it for now, instead.
Now (next release) it goes to the Japanese translator. Who goes, WTF
is this? Well, OK, maybe more like 「なにこれ？」
What used to be easily translated as "%d猫と%d犬" is now just "%d %s and
%d %s", or maybe by now "%1$d %2$s and %3$d %4$s". What's the context?
Should this be "%1$d%2$sと%3$d%4$s", "%1$d%2$sで、%3$d%4$s", or a dozen
other possibilities? Yes, the first guess is still really the only
likely answer given the presence of %d, but still, you've made the
translation job harder.
Given that the original was in English, which has plurals, the
programmer might have supplied that -- but consider if the original
were in Japanese, which almost entirely lacks the concept. Just like
English lacks the concept of a different set of number words for long
skinny things like pencils, vs flat sheets like paper. In that case,
the first time that plurals will enter the picture will be when the
app gets to the English translator, who will get to barf.
Note that even if the Japanese programmer writes it in English
originally, you're still probably going to have the same situation. In
fact, you're likely to have it even if English is your programmer's
native tongue.
In addition to translation, often the text and wording are manipulated
separately from the code, for marketing and/or usability and/or
branding purposes. So the original text may have been "Pigs: %d,
Cattle: %d", and now it's being rebranded for a pet store by someone
who doesn't even have access to the source, and they want to make the
text style more friendly -- and THIS is the first context in which
plurals need to be handled.
Bottom line on that point is that plurals are a linguistic concern,
and should not be institutionalized in Java code. Plural handling
should be fully externalized -- as part of the format syntax. Say,
perhaps, %(3:MyPlural)$s, which rather than directly referencing an
argument, references a <plural/>, and selects the case based on the
numeric value in parameter 3.
The bottom bottom line is, there really isn't much value in asking
programmers to write in the positional arguments. It's more economical
to do so at the point of reordering, which is only a small subset of
the cases - if you get to that point at all.
If you want to force programmers to do something useful -- force them
to define and document what each parameter MEANS. For example, if you
forced the programmer to give each parameter a NAME, instead of a
position in a getString(...) call, the extra effort would not be
duplicative, and you get some improved robustness for your efforts.
For a really radical suggestion:
in strings.xml: <string id='cats_and_dogs'>%(CATS)d %
(CATS:cat_plural)s and %(DOGS)d %(DOGS:dog_plural)s</string>
in Java: getFormatted(R.string.cats_and_dogs).p("DOGS",
dogCount).p("CATS", catCount).asText();
This fully removes order from the picture, provides some self-
documenting characteristics, separates the concerns properly -- and of
course, is completely incompatible with Java's formatting. Though it
is detectable which is which.
And maybe a translate='no' attribute -- then an automated script could
detect where a translator has mistakenly translated an identifier used
as a database key...very annoying...translation isn't the only reason
strings are externalized.
On Dec 6, 1:31 pm, Xavier Ducrohet <[email protected]> wrote:
> This suddenly appears because, starting with tools r8, applications
> are compiled using the latest version of aapt (the tool that compiles
> the android resource).
>
> We used to use version of aapt specific to the version of Android you
> compiled against, but not anymore.
>
> Benefits of using the latest versions:
> - if we add a feature, you'll get it even if you compile against an
> older version. For instance, the new mode that automatically insert
> debuggable="true" in your manifest would not be usable on older
> versions.
> - you get bug fixes too, or behavioral changes. In this case, aapt is
> more strict, and while that may be annoying at first, this is really
> important to use positional format.
>
> Xav
>
> On Mon, Dec 6, 2010 at 11:47 AM, Streets Of Boston
>
>
>
>
>
>
>
>
>
> <[email protected]> wrote:
> > When this string is in my strings.xml
>
> > <string name="home_activity_header_name">%s %s</string>
>
> > I get this error when compiling the source-code:
> > "error: Multiple substitutions specified in non-positional format; did
> > you mean to add the formatted="false" attribute"
>
> > I just upgraded to the newest tools (v 8.0.0) and downloaded the
> > latest SDK (2.3).
> > I compile under apil-leverl 8 and i tried compiling under api-level 9.
>
> > Why does this error suddenly appear?
> > Is there a way to get rid of it?
>
> > Thanks!
>
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Android Developers" group.
> > To post to this group, send email to [email protected]
> > To unsubscribe from this group, send email to
> > [email protected]
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
>
> --
> Xavier Ducrohet
> Android SDK Tech Lead
> Google Inc.
>
> Please do not send me questions directly. Thanks!
--
You received this message because you are subscribed to the Google
Groups "Android Developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/android-developers?hl=en
