[haiku] Re: Proposals for the LocaleKit
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku@xxxxxxxxxxxxx
- Date: Sun, 14 Feb 2010 16:09:30 +0100
On 2010-02-07 at 20:45:47 [+0100], Oliver Tappe <zooey@xxxxxxxxxxxxxxx> wrote:
> On 2010-02-07 at 16:27:53 [+0100], PulkoMandy <pulkomandy@xxxxxxxxx> wrote:
> > > But I thought it already does. Didn't Oliver mention this a while back?
> > > So
> > > it's really easy to rewrite those string composition pieces of code. If
> > > you
> > > see a piece of code like
> > >
> > > BString copyStatus;
> > > copyStatus << "File ";
> > > copyStatus << current;
> > > copyStatus << " of ";
> > > copyStatus << total;
> > > copyStatus << " copied.";
> > >
> > > Simply replace that with:
> > >
> > > char buffer[256];
> > > snprintf(buffer, sizeof(buffer), TR("File %1d of %2d copied."), current,
> > > total);
> > >
> > > The only drawback here is the fixed buffer size. But can some one say if
> > > this works? Will snprintf insert current and total at the correct
> > > locations?
> >
> > Yes it does. But that is not a nice way of showing our beautiful C++ API.
> > HAving a BString::SPrintf() method or something similar would make it
> > easier and avoid buffer problems.
As for the naming, I'd vote for BString::Format().
> How about:
>
> BStringBuilder builder = _TR("File %1s of %2s copied");
> BString result = builder << BIntFormatter(current) << BIntFormatter(total);
>
> or
>
> BString result = BStringBuilder(_TR("File %s of %s copied"))
> << BIntFormatter(current) << BIntFormatter(total);
>
> (the latter leaving out the positonal arguments as they match the default
> order).
>
> Please note: using %d or %f will only work locale-wise when the POSIX locale
> stuff has been implemented. Furthmore, the POSIX API is somewhat limited
> with
> respect to getting more information about the resulting string (where is the
> total number in that string?),
Actually printf() supports "%n" for that purpose. If we also want to format
more complex objects like dates/times this way, getting the position/width of
individual fields (e.g. seconds) would still be a problem, though.
> so I'd recommend to provide a string-only
> builder class (or whatever we name it) and then use type specific formatting
> objects to convert numbers/dates/times into strings.
I don't think this is generic enough. I guess the BIntFormatter() converts an
integer to a string taking an optional formatting specification including
field width, leading zeroes, etc. This might be translation-relevant
information, though (e.g. for ASCII fixed-width tables), so we might actually
need to pass it to the translation backend, too. Even worse are ordinal
numbers ("1 file", "2 files" -- potentially more cases in other languages),
which would require different strings depending on the value. For this
purpose I guess we need a simple language for the catalog files to select the
translation depending on the argument value. E.g.:
# "Found X matches in Y files."
(0, *): "Didn't find any match in any file."
(1, 1): "Found 1 match in 1 file."
(1, 2..): "Found 1 match in %2$d files."
# probably semantical nonsense
(2.., 1..): "Found %1$d matches in 1 file."
(2.., 2..): "Found %1$d matches in %2$d files."
Using standard printf() syntax for positional arguments here, BTW. Something
else might be more appropriate.
CU, Ingo
Other related posts:
