>>> [: Oswald Buddenhagen :]
>>> even more wrong when you cut characters while you have a pixel width and
>>> a proportional font. you wouldn't believe how hard it is to convince
>>> certain nokians of this rather obvious reality ... :} anyway, more valid
>>> use cases [for in-string formatting] ar
Let's make this a branch about i18n API. This includes call syntax (message
strings, overloading vs. distinct names), argument substitution syntax
(method, %-operator, templates), conversion to string (special classes,
implicit vs. explicit), catalog resolution (global vs. by domain).
I have no ro
I forgot to address this:
>> [: Oswald Buddenhagen :]
>> even more wrong when you cut characters while you have a pixel width and
>> a proportional font. you wouldn't believe how hard it is to convince
>> certain nokians of this rather obvious reality ... :} anyway, more valid
>> use cases [for in
This one is revisiting placeholder substitution alone. It should be
orthogonal to considerations of markup, conversion, and domains.
>> [: Chusslove Illich :]
>> In the "perfect text translation library" I would like that argument
>> placeholders are named and fully contained in mirror-character w
> [: Chusslove Ilich :]
> I can give you some numbers on current trunk/l10n-kde4/ POs:
>
> === Statistics by words ===
> Total: 917230
> [...]
> Total would-be unique without context at all: 816322 (+12.4% growth)
Sorry, this number is bogus. Here messages were compared across PO files
too
On Thursday 07 July 2011, Chusslove Illich wrote:
...
> What current library's Qt integration, that wouldn't be present in the
> standalone library? How would the implementation be less lightweight?
>
> I agree that few will want to pull in QtCore and QtScript just to be able
> to use this library
>> [: Chusslove Illich :]
>> [...] "they" weren't seriously thinking about disambiguation at all.
>
> [: Oswald Buddenhagen :]
> that's not entirely fair or even accurate.
Granted that I am assuming too much (maybe you're dealing with a vigilant
bunch), but in most scenarios I'd expect to be right
> [: Oswald Buddenhagen :]
> so in summary, you think we *should* go for semantic highlighting if the
> problems can be adequately solved, yes?
That is the summary, yes. But what I would want to make it adequate may be
too heavyweight, while the lightweight solutions you propose I don't
consider a
On Tue, Jul 05, 2011 at 05:09:38PM +0200, Chusslove Illich wrote:
> [: Oswald Buddenhagen :]
> > if one defines that KUIT is a superset of qt rich text, there is not even
> > a theoretical problem with it.
>
> But KUIT is supposed to be transformable into different target formats, of
> which Qt ri
On Tue, Jul 05, 2011 at 11:04:41AM +0200, Chusslove Illich wrote:
> [: Oswald Buddenhagen :]
> > - the class names cause many messages to be duplicated
>
> This is exactly the reason I was afraid someone had put out :) It basically
> reveals that "they" care zero about context. It shows you...
>
> [: Oswald Buddenhagen :]
> right, now i remember that we talked about that. auto-escaping is the only
> reasonable option. suppression should be done on a per-placeholder basis
> (which brings us to rich formats again). though i wonder how often you'd
> actually want to substitute a pre-quoted st
>>> [: Oswald Buddenhagen :]
>>> because "everyone" is complaining about the extra contexts, including
>>> our qml team.
>>
>> [: Chusslove Illich :]
>> I would be interested at what the concrete complaints were.
>
> [: Oswald Buddenhagen :]
> - class names are not meaningful in qml
>
> additionall
A Tuesday, July 05, 2011, Oswald Buddenhagen va escriure:
> - the ongoing basic feature duplication puts kde into a bad light
That made my day :-)
Albert
On Tue, Jul 05, 2011 at 12:57:27AM +0200, Chusslove Illich wrote:
> > [: Oswald Buddenhagen :]
> > because "everyone" is complaining about the extra contexts, including our
> > qml team.
>
> I would be interested at what the concrete complaints were.
>
- the class names cause many messages to be d
> [: Oswald Buddenhagen :]
> because "everyone" is complaining about the extra contexts, including our
> qml team. so there will be change. the question is what is necessary to
> compensate it (@tags) and what we can usefully piggy-back on it as we
> change anyway.
I would be interested at what th
On Mon, Jul 04, 2011 at 04:46:27PM +0200, Chusslove Illich wrote:
> > [: Oswald Buddenhagen :]
> I don't think there is a clear benefit in unifying KDE and Qt translation
> systems.
>
> _From the point of view of Qt, considering their paying customers, why
> change anything in Linguist system?
>
b
> [: Oswald Buddenhagen :]
> fwiw, somebody has to actually do the work if anything is supposed to
> happen with qt's translation framework, and it doesn't look like any troll
> has the capacity. we need to assess what is in kde, what can be directly
> reused, what needs a rewrite, and who has time
On Sat, Jul 02, 2011 at 07:27:35PM +0200, Chusslove Illich wrote:
> When text contains markup, some special characters need to be escaped
> when they are wanted literally in the text.
>
that's why the decision whether QUIT (haha, what a pun) is wanted needs
to be done before 5.0.
> This leads to t
On Sun, Jul 03, 2011 at 03:32:44PM +0200, Chusslove Illich wrote:
> [Michael Olbrich's response:]
> No implicit conversion. That just asks for trouble. You don't know whether
> the QString stored in the QVariant is before or after the arguments are
> passed. If its before you would loose [KLocalize
On Sun, Jul 03, 2011 at 01:06:40AM +0200, Chusslove Illich wrote:
> >> [: Chusslove Illich :]
> >> * PO has to be natively supported. [...] The real advantage instead is in
> >> the format and the process; and also tool support on translators' side.
> >
> > [: Oswald Buddenhagen :]
> > how is the p
> [: Chusslove Ilich :]
> [...] I no longer remember why I thought implicit conversion is dangerous;
> and why people didn't throw at me "don't be stupid, add implicit
> conversion". I'll have to do some digging...
Here is the argument (September 2005), cut to measure:
-- start --
>> [: Chusslove Illich :]
>> * PO has to be natively supported. [...] The real advantage instead is in
>> the format and the process; and also tool support on translators' side.
>
> [: Oswald Buddenhagen :]
> how is the process fundamentally different from the linguist toolchain?
> why would the fo
On Sat, Jul 02, 2011 at 02:51:54PM +0200, Chusslove Illich wrote:
> * PO has to be natively supported.
>
it already is.
> By this I do not mean merely use of MO files at runtime,
>
given that MO is not a subset of PO, this is pretty self-evident. :P
> but the whole process:
> xgettext for extrac
>> [: Oswald Buddenhagen :]
>> - for the inline markup, chusslove gave me a list with 10-15 items when i
>> asked "what would you do differently if you could do KUIT again?". half
>> of it is all greek to me [...]
>
> [: Chusslove Illich :]
> [...] convert that list of problems that I gave you into
>> [: John Layt :]
>> * New QStringFormatter to solve tr() args problem. Community to code? [I
>> don't understand the problem or solution here :-)]
>
> [: Oswald Buddenhagen :]
> the problems to solve:
> [...]
Given the general direction of these localization-related messages, should I
assume tha
A Thursday, June 30, 2011, Oswald Buddenhagen va escriure:
> On Wed, Jun 29, 2011 at 09:04:40PM +0100, John Layt wrote:
> > * New QStringFormatter to solve tr() args problem. Community to code? [I
> > don't understand the problem or solution here :-)]
>
> the problems to solve:
> - localization-s
On Wed, Jun 29, 2011 at 09:04:40PM +0100, John Layt wrote:
> * New QStringFormatter to solve tr() args problem. Community to code? [I
> don't understand the problem or solution here :-)]
>
the problems to solve:
- localization-specific string formatting, i.e., making the format part
of the tra
27 matches
Mail list logo
