BTW: if by 2200 UTC none of the two solutions mentioned above (continuation lines, or single long lines) is implemented, I will revert the majority of a798e78d477e (leaving only the .pot renaming, which is correct).

In D23783#527719, @romangg wrote:

In D23783#527582, @pino wrote:

It's a normal QML function ...

If it's just a QML function why is it a problem to + some strings when providing them as an argument?

In D23783#527600, @romangg wrote:

diff --git a/kcm/package/contents/ui/main.qml b/kcm/package/contents/ui/main.qml
index 2e61aa5..191daf3 100644
--- a/kcm/package/contents/ui/main.qml
+++ b/kcm/package/contents/ui/main.qml
@@ -41,8 +41,8 @@ KCM.SimpleKCM {
 
             Layout.fillWidth: true
             type: Kirigami.MessageType.Warning
-            text: i18n("Are you sure you want to disable all outputs? ") +
-                  i18n("This might render the device unusable.")
+            text: i18n("Are you sure you want to disable all outputs? \
+This might render the device unusable.")
             showCloseButton: true
 
             actions: [

This also works, but it's ugly because the second line has not the right indent.

In D23783#527581, @romangg wrote:

In D23783#527579, @pino wrote:

Which macro?

i18n(...) or "function"?

In D23783#527575, @romangg wrote:

In D23783#527562, @pino wrote:

Please do not split the messages just for sake of column width.

If there is a better solution than splitting text with a + while still respecting the line chars limit I will upload a new patch.

Please do not split the messages just for sake of column width.

please use QCOMPARE/QVERIFY instead of Q_ASSERT in QTest tests

Oh, and also please add tests for them in UDSEntryTest.

Please move the implementations in the cpp file, otherwise it will be impossible to change/fix the implementation later on in a binary compatible way.

(Not arguing for or against this patch, just providing more info on the Fedora situation.)

FWIW there is a typo in the commit title: "Aurorea" -> "Aurorae"

In D23309#516337, @yurchor wrote:

The only problem with https://krusader.org/get-involved/ is that it is even more conservative than our user docs

In D23309#515733, @asensi wrote:

Note: There are some reasons why Krusader users have documentation available in their computers, maybe Yuri Chornoivan can give more information about it.

TBH I'd just add the instructions to https://krusader.org/get-involved/, and not to the user documentation.
Just like we do not add compilation/build instructions to documentations anymore, IMHO it makes sense to not add contribution instructions either: they are generally not related to "using the application", and thus the old documentation shipped with an old version would show outdated links. Some of the changes in this patch perfectly show this: imagine that users installing krusader in stable distros have outdated links to freshmeat and linux-apps in the documentation they read.

This looks like a workaround to me: if installedVersion is not available (is it known when, actually?), why keep using it anyway, with or without i18n?
Also, -1 to string puzzles and to UI strings not translatable.

In D23224#513556, @z3ntu wrote:

I'm guessing the changed English strings will trigger a "untranslated string" warning in the translation software, so the translators should notice it, right?

Please do not change the translations manually -- there is an automatic system that takes care of extracting the English strings, and merging back the translators for desktop/json/xml/alike files.

It is implemented purely as a setting in the settings dialog rather than a new
part of the save dialog because that would add a kdelibs4support dependency and
not be compatible with Flatpak portals.

why did you abandon this?

Please do not manually change translated keys in desktop files: there is an automatic system that takes care of them.

In D22836#504394, @davidre wrote:

In D22836#504355, @kossebau wrote:

That as well, as also discussed on irc today.

Just in case that other scripts on api.kde.org do not work yet with Python3 or no-one has time to test that, this patch might allow to at least get the api.kde.org being updated again, which it was not since April for all the repos covered by kapidox.

I agree that getting api.kde.org uo to date again is a priority.

In D22836#504393, @aacid wrote:

Ok, yep i may have misunderstood :)

But if you say "kapidox supports Python 2.7" we need to commit this to keep it true :)

In D22836#504389, @aacid wrote:

Pino please take a step back and rethink your position.
Yes, supporting Python2 sucks, but this is 2 lines of code while porting everything to Python 3 is lots of work more.

Let me add one more thing: I understand you care about API docs, about making them available for our users on api.kde.org, and about giving the best impression possible about them (I remember various patches about that in the past).

In D22836#504359, @kossebau wrote:

In D22836#504358, @pino wrote:

Oh dear, and what about switching the api generation to Python 3 instead?

Nobody is stopped to work on that. I am not a Python expert, I just providing here the small fix which fall off from me local testing at why the build fails. Which also includes testing whether the bug reproduced locally also is seen with Python3 (it is not). Sorry if I left out this details here, they had been mentioned on Sysadmin.

This fix could "potentially" just buy some more time, and not solve the issue of keep using Python 2 further.

Keeping things broken has not worked to make you switch api.kde.org to Python3, right? ;)

In D22836#504357, @kossebau wrote:

In D22836#504356, @pino wrote:

In D22836#504355, @kossebau wrote:

Just in case that other scripts on api.kde.org do not work yet with Python3 or no-one has time to test that,

At this point, making Python stuff work with Python3 is priority one.

Oh dear, any chance we could look at this simple fix provided here, which get us potentially api.kde.org back the day this simple patch is confirmed and in?

In D22836#504355, @kossebau wrote:

Just in case that other scripts on api.kde.org do not work yet with Python3 or no-one has time to test that,

Or maybe just drop support for Python 2 entirely?

• kapidox is rarely used
• Python 2 will be EOL in 5 months
• distros either switched kapidox to Python 3, or will do it soon

I'd say to commit it directly - it's your website, after all.

other than building, please also check that it actually still works on Linux

In D22616#499453, @nicolasfella wrote:

@sitter said he has a version of the settings to be integtated into phonon so the remaining three users can still access them

this

Erm, so what if you do not use plasma-pa?

In D22605#499051, @alexde wrote:

I would like to test it and post a screenshot, however I am not able to compile it:

1. I cloned the source from the git repository
2. mkdir plasma-workspace/applets/notifications/build
3. cd plasma-workspace/applets/notifications/build
4. cmake ..
   
   This resulted in ` CMake Error at CMakeLists.txt:11 (kcoreaddons_desktop_to_json): Unknown CMake command "kcoreaddons_desktop_to_json". `

Patch landed, and build successfully everywhere.
Congratulations for your first patch :)

Do you have permissions to push patches on your own? If not, please specify your email so I can properly attribute this patch to you.

@sgerlach why?? please do NOT copy translations statically into sources!

How would first + last name work, when
a) you have multiple first names
b) you have multiple last names
c) you have only one "name" -- http://wookware.org/name.html

In D22210#498929, @asturmlechner wrote:

drop translations

Since you are changing the strings, I suggest changing them to bein line with the HIG:
https://hig.kde.org/style/writing/capitalization.html

In D22545#498239, @usta wrote:

i will just commit this to master or do i need to xommit to a branch then merge it to master ?