Reformatted for readability after the newsgroup reformats it:
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();
Also, as I think this is an issue which transcends Android, I've
posted a reworded version of this on my blog:
http://bobkerns.typepad.com/bob_kerns_thinking/2010/12/dear-java-better-text-formatting-please.html
Feel free to comment about non-Android aspects there.
On Dec 6, 9:57 pm, Bob Kerns <[email protected]> wrote:
> 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
