How does this ‘fix’ https://bugs.kde.org/show_bug.cgi?id=198872?

In D13219#499990, @huftis wrote:>

I’ve just tested this, but changing %1 to %L1 doesn’t seem work; the %L1 is displayed verbatim.

In D13219#302802, @safaalfulaij wrote:

Since this turned already into a discussion, shall we use %Lx version for KF5 libraries using Qt's translation system? I mean in the source text.

Human's life is short. Can we have a "grace" period (say 3 years)?

I still object to this being merged, the actual problem has to be fixed, not workarounded in every single app.

QLocale().toString is the only thing that currently works. No other ways, like the recommended [1] ki18n*() with subs() or another formatting, do work.

In D17364#371591, @ltoscano wrote:

Uhm, the review landed already in the previous version (before some comments) and on master?

Uhm, the review landed already in the previous version (before some comments) and on master?

If this is targeted to Applications/18.12 as I think it is, the doc change would break the freeze. I'd suggest to leave out index.docbook from this change, and only fix it after merging the change into the master branch.

Update doc

Use cmake versioning

In D17364#371550, @ltoscano wrote:

(if you want more time to think about this, given that the tagging of Applications 18.12 is tomorrow, I'd suggest to bump the version to 2.1 on the Applications/18.12 branch now anyway)

(if you want more time to think about this, given that the tagging of Applications 18.12 is tomorrow, I'd suggest to bump the version to 2.1 on the Applications/18.12 branch now anyway)

The version should be definitely increased at this point.
As the new de-facto maintainer, I'd say that you can bump the version to whatever version you want.

Please change the version in DocBook as well

Dead runners will surely be empty on the first load. You could still have had a locale change then.

No time and insight, sorry.

In T4474#162198, @sdepiets wrote:

What about a reservation system within lokalize, a coordinator would be able to update a reservation status on each file from the Project View then commit the reservations to SVN.

It would host a flat file that would be stored on SVN, and the site would just display these meta-information (we could add new columns if needed).

What about a reservation system within lokalize, a coordinator would be able to update a reservation status on each file from the Project View then commit the reservations to SVN.

For me seems ok now.

Memory leak fix + limit to one KProcess at a time

Otherwise all seems ok for me.

Patch improvements

Patch improvements

I've made the following changes :

• Moved the config from project to application
• Set up default values for the command lines
• Gray out the option in the editor tab when pology is disabled
• Add a pop-up on success (else you don't know when it's over)

• Redirect error messages

• Escaping the file names with double-quotes (maybe that's where your problem is coming from, now the command line is output if you launch from a terminal so you should be able to try the command manually)

In D15759#332366, @huftis wrote:

As for displaying the results, having a separate ‘Pology results’ pane showing the results would be nice (click on an error to jump to the message with the error).

And perhaps a ‘Pology errors’ column in the Project View (which would show the number of errors in each file – ‘0’ if no errors, ‘–’ if the file hasn’t been checked yet, or if it has been changed since the last check).

As for displaying the results, having a separate ‘Pology results’ pane showing the results would be nice (click on an error to jump to the message with the error).

Thanks for adding support for this!

Removed useless condition