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?
> 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 android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en
-- Romain Guy Android framework engineer romain...@android.com
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them
The snipped from the strings.xml in my post above is just an example.
It happens when the value of a string-property has more than one
substitution, e.g.
<string name="page_number">Page %d out of %d</string>
has the same problem.
This has never been a problem before and I'm using it in my app
correctly.... until I upgraded to SDK 2.3/Tools 8.0.0 just now.
Please help...
On Dec 6, 2:47 pm, Streets Of Boston <flyingdutc...@gmail.com> wrote:
> 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?
> > 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 android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com>
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
> Note: please don't send private questions to me, as I don't have time to
> provide private support. All such questions should be posted on public
> forums, where I and others can see and answer them- Hide quoted text -
> On Dec 6, 2:56 pm, Romain Guy <romain...@android.com> wrote: > > To make this work correctly across multiple locales, you should use the > > following syntax:
> > $1%s $2%s
> > On Mon, Dec 6, 2010 at 11:47 AM, Streets Of Boston > > <flyingdutc...@gmail.com>wrote:
> > > 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 > android-developers@googlegroups.com > > > To unsubscribe from this group, send email to > > > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > <android-developers%2Bunsubscribe@googlegroups.com> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en
> > Note: please don't send private questions to me, as I don't have time to > > provide private support. All such questions should be posted on public > > forums, where I and others can see and answer them- Hide quoted text -
> > - Show quoted text -
> -- > 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+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en
-- Romain Guy Android framework engineer romain...@android.com
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them
It wouldn't. What if you translate your app in a language where the second value should appear first? The translation would be $2%s $1%s and the code wouldn't change.
On Mon, Dec 6, 2010 at 12:04 PM, Streets Of Boston <flyingdutc...@gmail.com>wrote:
> I thought that the position/order of the arguments of the code that > calls the getString method would take care of this.
> On Dec 6, 2:56 pm, Romain Guy <romain...@android.com> wrote: > > To make this work correctly across multiple locales, you should use the > > following syntax:
> > $1%s $2%s
> > On Mon, Dec 6, 2010 at 11:47 AM, Streets Of Boston > > <flyingdutc...@gmail.com>wrote:
> > > 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 > android-developers@googlegroups.com > > > To unsubscribe from this group, send email to > > > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > <android-developers%2Bunsubscribe@googlegroups.com> > > > For more options, visit this group at > > >http://groups.google.com/group/android-developers?hl=en
> > Note: please don't send private questions to me, as I don't have time to > > provide private support. All such questions should be posted on public > > forums, where I and others can see and answer them- Hide quoted text -
> > - Show quoted text -
> -- > 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+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com> > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en
-- Romain Guy Android framework engineer romain...@android.com
Note: please don't send private questions to me, as I don't have time to provide private support. All such questions should be posted on public forums, where I and others can see and answer them
On Dec 6, 3:08 pm, Romain Guy <romain...@android.com> wrote:
> It wouldn't. What if you translate your app in a language where the second
> value should appear first? The translation would be $2%s $1%s and the code
> wouldn't change.
That may be the case, sometimes, somewhere. It isn't all the time.
There may have been some developers giving strings to a translation
company who returned the string translations and didn't tell the
developers that the order of %s and %s was different, and the software
company didn't have any QA in place to catch this, so some strings
appeared funny for that particular translation.
I don't think the answer to solve this problem, that probably happened
once to someone, with a build error instead of a warning.
> It wouldn't. What if you translate your app in a language where the second
> value should appear first? The translation would be $2%s $1%s and the code
> wouldn't change.
> On Mon, Dec 6, 2010 at 12:04 PM, Streets Of Boston
> <flyingdutc...@gmail.com>wrote:
> > Thank you!
> > That's new to me, though....
> > I thought that the position/order of the arguments of the code that
> > calls the getString method would take care of this.
> > On Dec 6, 2:56 pm, Romain Guy <romain...@android.com> wrote:
> > > To make this work correctly across multiple locales, you should use the
> > > following syntax:
> > > $1%s $2%s
> > > On Mon, Dec 6, 2010 at 11:47 AM, Streets Of Boston
> > > <flyingdutc...@gmail.com>wrote:
> > > > 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
> > android-developers@googlegroups.com
> > > > To unsubscribe from this group, send email to
> > > > android-developers+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com>
> > <android-developers%2Bunsubscribe@googlegroups.com>
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/android-developers?hl=en
> > > Note: please don't send private questions to me, as I don't have time to
> > > provide private support. All such questions should be posted on public
> > > forums, where I and others can see and answer them- Hide quoted text -
> > > - Show quoted text -
> > --
> > 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+unsubscribe@googlegroups.com<android-developers%2Bunsubs cribe@googlegroups.com>
> > For more options, visit this group at
> >http://groups.google.com/group/android-developers?hl=en
> Note: please don't send private questions to me, as I don't have time to
> provide private support. All such questions should be posted on public
> forums, where I and others can see and answer them
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
> 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 android-developers@googlegroups.com > To unsubscribe from this group, send email to > android-developers+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en
-- Xavier Ducrohet Android SDK Tech Lead Google Inc.
I agree that for internationalization the order spec is important.
However, i read through the changes in the tools and SDK2.3 and I
didn't read about this particular change in aapt (where position is
now required, unless formatted="false" is used). Therefore, the error
came by surprise and it took me a while to figure out (thanks
Romain!).
Also, I only found an example of the positional parameters (1$, 2$,
etc) in an example on this page:
http://developer.android.com/guide/topics/resources/string-resource.html.
I assume that the format is "n$", where n is a digit (or more digits?)
that should appear right after the '%' character. Is this correct? If
not, where can i find more info on this particular format (the
Formatter java-doc does not say anything about the positional
parameters)..
On Dec 6, 4:31 pm, Xavier Ducrohet <x...@android.com> 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
> <flyingdutc...@gmail.com> wrote:
> > When this string is in my strings.xml
> > 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 android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscribe@googlegroups.com
> > 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!- Hide quoted text -
<flyingdutc...@gmail.com> wrote: > Also, I only found an example of the positional parameters (1$, 2$, > etc) in an example on this page: > http://developer.android.com/guide/topics/resources/string-resource.html. > I assume that the format is "n$", where n is a digit (or more digits?) > that should appear right after the '%' character. Is this correct? If > not, where can i find more info on this particular format (the > Formatter java-doc does not say anything about the positional > parameters)..
Sure it does. Sixth paragraph under Class Overview:
"Argument index. Normally, each format specifier consumes the next argument to format. For convenient localization, it's possible to reorder arguments so that they appear in a different order in the output than the order in which they were supplied. For example, "%4$s" formats the fourth argument (4$) as a string (s)."
> On Mon, Dec 6, 2010 at 5:18 PM, Streets Of Boston
> <flyingdutc...@gmail.com> wrote:
> > Also, I only found an example of the positional parameters (1$, 2$,
> > etc) in an example on this page:
> >http://developer.android.com/guide/topics/resources/string-resource.html.
> > I assume that the format is "n$", where n is a digit (or more digits?)
> > that should appear right after the '%' character. Is this correct? If
> > not, where can i find more info on this particular format (the
> > Formatter java-doc does not say anything about the positional
> > parameters)..
> Sure it does. Sixth paragraph under Class Overview:
> "Argument index. Normally, each format specifier consumes the next
> argument to format. For convenient localization, it's possible to
> reorder arguments so that they appear in a different order in the
> output than the order in which they were supplied. For example, "%4$s"
> formats the fourth argument (4$) as a string (s)."
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 <x...@android.com> 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
> <flyingdutc...@gmail.com> wrote:
> > When this string is in my strings.xml
> > 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 android-developers@googlegroups.com
> > To unsubscribe from this group, send email to
> > android-developers+unsubscribe@googlegroups.com
> > 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!
> 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 <x...@android.com> 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
> > <flyingdutc...@gmail.com> wrote:
> > > When this string is in my strings.xml
> > > 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 android-developers@googlegroups.com
> > > To unsubscribe from this group, send email to
> > > android-developers+unsubscribe@googlegroups.com
> > > 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!
I agree with Bob that an error is a bit over the top. E.g. I include
software from another company as a library project in one of my apps.
This foreign software uses the old formatting using %s %s inside a few
strings, which is now reported as an error. Now I can neither change
the string, because this might break functionality, nor may I use the
new SDK because this produces an error where a warning would have been
sufficient. So I am stuck with Android 2.2 SDK :-(.
> 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.
On Tue, Dec 7, 2010 at 4:42 AM, Ecthelion <ep...@joergjahnke.de> wrote: > I agree with Bob that an error is a bit over the top. E.g. I include > software from another company as a library project in one of my apps. > This foreign software uses the old formatting using %s %s inside a few > strings, which is now reported as an error. Now I can neither change > the string, because this might break functionality, nor may I use the > new SDK because this produces an error where a warning would have been > sufficient. So I am stuck with Android 2.2 SDK :-(.
If it is an Android library project, you can definitely change the string. That's half of the point of *having* Android library projects -- so developers can modify resources as needed. In your project, override the library's string resource with one of your own with the same name, and it will be used. You do not have to modify the actual library project yourself.
Yes, if the library project includes all the sources. But in this case
part of the foreign code is inside a jar file. And can I really be
sure that the string is not used somewhere inside this library (e.g.
via getResources().getIdentifier(...)) in a way that breaks once I
modify the resource? In any case I still believe that issueing an
error instead of a warning is over the top.
On 7 Dez., 13:45, Mark Murphy <mmur...@commonsware.com> wrote:
> If it is an Android library project, you can definitely change the
> string. That's half of the point of *having* Android library projects
> -- so developers can modify resources as needed. In your project,
> override the library's string resource with one of your own with the
> same name, and it will be used. You do not have to modify the actual
> library project yourself.
On Tue, Dec 7, 2010 at 10:35 AM, Ecthelion <ep...@joergjahnke.de> wrote: > Yes, if the library project includes all the sources. But in this case > part of the foreign code is inside a jar file.
Resources cannot be in a JAR file.
> And can I really be > sure that the string is not used somewhere inside this library (e.g. > via getResources().getIdentifier(...)) in a way that breaks once I > modify the resource?
Yes.
> In any case I still believe that issueing an > error instead of a warning is over the top.
Class.getResource(String) and friends vs. Context.getResources() and
friends. To add to the confusion, they really *are* performing the
same task, albeit differently and on disjoint data.
The stuff inside a .jar file is accessed with
Class.getResource(String), while strings.xml is accessed via
Context.getResources().
To add further to the confusion, most of my comments could apply to
either, but the main discussion is referring to
Context.getResources().
On Dec 7, 7:39 am, Mark Murphy <mmur...@commonsware.com> wrote:
> On Tue, Dec 7, 2010 at 10:35 AM, Ecthelion <ep...@joergjahnke.de> wrote:
> > Yes, if the library project includes all the sources. But in this case
> > part of the foreign code is inside a jar file.
2. To the guys who think the errors for the multiple formatters is
over the top... it isn't just over the top, it has really screwed us
over!
I guarantee you what happened is that someone working with Google
wasn't using positional formatters in the strings, and in the latest
batch of translations, one of the positions was supposed to be moved
and it wasn't. So, one person at Google (maybe Romain? he was talking
about it's reasoning earlier) decided that it should be an error for
all people everywhere, because of the screwup in the translation. It
wouldn't have been a problem if this was the way it started out when
Android was initially released, but what actually happened is that the
innocent upgrading of the latest SDK (even though you're supposed to
be able to use any older API levels you want) has made all of our
projects break.
It has made a lot of unnecessary work for me and my team. We've got
multiple projects with a build machine, everything's F'd now. If you
upgrade the SDK Tools on the build machine, half the projects don't
release. Not only that, the same project can have multiple branches
in git. Even as good as git's merging abilities are, after changing
all of the various strings in various branches (which change often),
now the strings.xml is hell to merge when you add in formatted="false"
to the line. To create a hotfix on an older version, we are forced to
make manual changes on these old branches.
To put it succinctly, this seemingly innocuous "feature" to error on
all these types of strings whereas before it didn't has invalidated
every old build in our system, period. There's no way to turn it off,
even if you set the API level to 1. We can no longer build anything
before 12/6/2010, without creating a special separate build machine
which has an old version of the tools on it.
Okay, this rant is over, have a good rest of your day!
On 7 Dez., 16:39, Mark Murphy <mmur...@commonsware.com> wrote:
> On Tue, Dec 7, 2010 at 10:35 AM, Ecthelion <ep...@joergjahnke.de> wrote:
> > Yes, if the library project includes all the sources. But in this case
> > part of the foreign code is inside a jar file.
> Resources cannot be in a JAR file.
Yes, but I never said so. I said foreign "code" is inside the jar
file.
> > And can I really be
> > sure that the string is not used somewhere inside this library (e.g.
> > via getResources().getIdentifier(...)) in a way that breaks once I
> > modify the resource?
> Yes.
Sorry, but the answer is "no".
Context.getResources().getIdentifier(...) allows any resource inside
the project to be accessed via its name. So there could be code inside
the library jar that accesses the string properties that I am to
modify because they contain "%s %s" or similar text. And I can't be
sure that such text then gets processed correctly.
On Wed, Dec 8, 2010 at 4:01 AM, Ecthelion <ep...@joergjahnke.de> wrote: >> > And can I really be >> > sure that the string is not used somewhere inside this library (e.g. >> > via getResources().getIdentifier(...)) in a way that breaks once I >> > modify the resource?
>> Yes.
> Sorry, but the answer is "no".
No, the answer is yes.
> Context.getResources().getIdentifier(...) allows any resource inside > the project to be accessed via its name.
Correct.
> So there could be code inside > the library jar that accesses the string properties that I am to > modify because they contain "%s %s" or similar text.
Correct.
> And I can't be > sure that such text then gets processed correctly.
Sure you can. It will be no different than if they accessed the string via R.string.whatever.
On 8 Dez., 15:14, Mark Murphy <mmur...@commonsware.com> wrote:
> Sure you can. It will be no different than if they accessed the string
> via R.string.whatever.
Yes. And how would you know how the jar library is processing the
string if the code lies (obfuscated btw.) inside the library? I might
grep the library for all resource names with "%s %s" (or the like)
where I made changes. But if I should find one of these resource names
thereby, how will I know whether the code inside the library relies on
the old string format or whether it works fine with the new "%1$s
%2$s"?
On Wed, Dec 8, 2010 at 2:40 PM, Ecthelion <ep...@joergjahnke.de> wrote: > Yes. And how would you know how the jar library is processing the > string if the code lies (obfuscated btw.) inside the library? I might > grep the library for all resource names with "%s %s" (or the like) > where I made changes. But if I should find one of these resource names > thereby, how will I know whether the code inside the library relies on > the old string format or whether it works fine with the new "%1$s > %2$s"?
