On Tuesday 07 July 2009 20:59:40 Albert Astals Cid wrote:
> A Dimecres 08 Juliol 2009 02:19:51, Aaron J. Seigo va escriure:
> > On Tuesday 07 July 2009, Burkhard Lück wrote:
> > > Am Mittwoch 08 Juli 2009 00:24:59 schrieb Albert Astals Cid:
> > > > Any reason you create "malformed" english messages instead correct
> > > > ones?
> >
> > we didn't. web services did. welcome to web 2.0, a world in which i18n
> > isn't thought about at all, or at least very very rarely, it seems and
> > all sorts of language oddities exist. it's a PITA and it's only going to
> > become more common.
>
> Hmmm, what does this have to do with malformed english texts?
>
> The code can be:
>
> if (text == "SomeEnglishMalformedText) return i18n("Some english nice
> text")
>
> or can't it? Because after all if we are getting translations you'll be
> hardcoding the malformed texts somewhere.
Well, I could use a static QMap for each malformed string and have this
automatically matched used in a function.
myConditionStrings["thunderstorm rain hail fog"] = i18n("Thunderstorm with
rain, hail and fog");
It just means for some data sources we'll need 300 lines of this :(
If anyone has some ideas to make this easier, I'd be glad to add this code to
the ion (data provider) sources today.
Thanks,
Shawn.
>
> > > cause none of our devels uses the language x-test?
> >
> > that's quite true. and those who use a translation but work on trunk are
> > used to seeing a mix of translated and non-translated so they aren't much
> > help. ;)
> >
> > i wonder what could be done to make using x-test easier? it's really a
> > bit of a pain to learn how the l10n module works, compile and install
> > x-test, switch to it as your language (and then switch back when you get
> > tired of it ;), update it and test with it regularly ... there must be
> > some way to make that more efficient and more attractive to developers?
>
> run script
> cmake
> make install
> KDE_LANG=x-test yourApplication
>
> I'm sure it can be made easier but don't know how.
>
> > > i18n = the second class citizen in kde
> >
> > some of us are actually _trying_ to care about things like RTL, i18n,
> > a11y, usability and various other things that expand our own
> > responsibilities and the complexity of our work immensely. i don't want
> > people to go back to ignoring these important things, but that is exactly
> > what will happen if we build artificial barriers through our language and
> > actions.
>
> There's no action against you at all, just complaining things like this
> should have been fixed when i complained back then, not now so close to
> release.
>
> > maybe we need an i18n dev sprint to get a bunch of the i18n people
> > together to improve processes,
>
> Of course our processes can be improved as everything can be, but take in
> mind that we have probably the best processes in the FLOSS community. Or
> that's what Chusslove always tells me.
>
> > work on some of the tools we have, create better
> > community bonds and even vent a bit in person ;) ... but please, let's
> > keep it positive when we work together here, ok?
> >
> > and yes, i'm serious about an i18n dev sprint. what do you think?
>
> It might be a nice place so i can find someone to replace me somewhen
> someday i'd like to step down from this position.
>
> Albert
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
