[haiku] Re: Proposals for the LocaleKit
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Mon, 15 Feb 2010 12:11:18 +0100
On 2010-02-15 at 09:59:42 [+0100], PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
> Le Mon, 15 Feb 2010 07:39:07 +0100, Jonas Sundström <jonas@xxxxxxxxxxx> a
> écrit:
>
> > Travis D. Reed "Travis D. Reed" <tdreed@xxxxxxxxx> wrote:
> > ...
> >> regex
> > ...
> >> How to handle this is a problem for ICU, too,
> >> because you have to expose translators to this.
> > ...
> >> > This will need to be sufficiently complex enough
> >
> > Can one assume we need to approximate a turing-complete
> > string-composition scriplet language, to offer to translators
> > of these tougher cases?
> >
> > Can we make one that is fast, simple to use, easy to learn
> > and yet very powerful?
> >
> > I'm thinking one can sandbox the complexity of each tough
> > language by leaving that language to describe its complexity
> > in such scriplets, per catalog entry, avoiding to expose
> > everyone (translators and developers) to the combined complexity
> > of all translation targets.
> >
> > Or maybe the morning coffee didn't take at all.
>
> wait wait,...
>
> ICU already provides it, of course.
> There is an API called MessageFormat. It handles ChoiceFormat,
> PluralFormat and SelectFormat, each following a set of rules that are set
> by the selected language.
> Here is an example for SelectFormat:
> http://site.icu-project.org/design/formatting/select
>
> The PluralFormat class is made to handle the polish and russian case. The
> specifiers you can use by default are zero, one, two, few and many. The
> "few" specifier looks like it maps to the weird thing we need in polish.
> Other languages may define other specifiers, and it is even possible to
> use regexps directly into the string for the corner cases if there are
> some left.
I suppose ICU already comes with the PluralRules for virtually all
languages, so I guess it would make sense to use it for this purpose (or at
least the rules).
> As for the implementation, this will take the form of a BStringBuilder
> API. It can't be made part of BString directly for now, as it would
> depends on ICU and then live in liblocale.so.
If ICU is used to implement POSIX locale support, we'll even need to have
it available in libroot. That is using ICU in BString wouldn't be a problem.
CU, Ingo
Other related posts:
