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