Zanshin is in kdereview
Luigi Toscano
luigi.toscano at tiscali.it
Fri Jun 23 15:11:12 BST 2017
On Friday, 23 June 2017 16:08:31 CEST Kevin Ottens wrote:
> Hello,
>
> On Tuesday, 20 June 2017 22:14:33 CEST Kevin Ottens wrote:
> > On Monday, 19 June 2017 21:50:16 CEST Luigi Toscano wrote:
> > > [...]
> > > I'm not sure why you didn't like the above solution.
> >
> > Just more work over time, and I don't have the bandwidth ATM. Typically we
> > tend to assume ki18n and a single catalog as the common case (and rightly
> > so), so does releaseme assume that too? And then I have to think about
> > both
> > files for shipping, etc.
> >
> > I just don't have the energy to think all that through so I'd rather go
> > the
> > lazy and easy path with the patch I did.
> >
> > > Now, can we properly discuss this? I don't want people coming back and
> > > saying that a solution was forced for $reasons when it was not forced at
> > > all. (that said, KI18n is better, but again you don't need to use it).
> > >
> > > > This one switches it all to i18n: https://phabricator.kde.org/D6283
> > >
> > > I'm going to put a -1 until we discuss this properly.
> >
> > Hope the above clarifies my reasons a bit.
> >
> > In a nutshell: tr() was used for an hypothetical mobile port, this port is
> > still not in sight with the bandwidth I currently have and tr() is
> > creating
> > me troubles mainly due to the kparts plugins; so either I drop said
> > plugins
> > or I switch to i18n to be like everyone else. I'm going for being like
> > everyone else.
> >
> > It can always be revisited later if there's really a mobile port or such
> > emerging.
>
> Can we lift the -1, review that patch and move on now?
There is a legitimate request change linked to the -1, as stated in the
review.
--
Luigi
More information about the kde-core-devel
mailing list