Re: "Configure Language" option
El dimecres, 26 d’octubre de 2022, a les 0:18:16 (CEST), Stefan Gerlach va escriure: > On 10/25/22 23:29, Albert Astals Cid wrote: > > El dilluns, 24 d’octubre de 2022, a les 23:38:15 (CEST), Stefan Gerlach va > > > > escriure: > >> Hello, > >> > >> i noticed that several KDE apps lack the ability to switch the UI > >> language > >> when using the "Configure Language" dialog. The .mo files are correctly > >> installed, all the languages are in the selection box and the > >> configuration > >> is saved in the klanguageoverridesrc file which is read on startup. But > >> somehow (most of) the UI strings are shown in the system language only. > >> I've seen this problem on Linux and Windows (macOS is probably not > >> better) > >> and am especially interested in making this work for LabPlot. You can > >> also > >> checkout Step which has the same problem. Anyone knows what may be > >> missing > >> or what needs to be done for this feature to work? > > > > If you have a modern KF5 there's a big set of warnings that tell you > > what's > > wrong > > > > https://invent.kde.org/education/labplot/-/merge_requests/173 > > > > After fixing that i can get labplot in Ukranian instead of my regular > > Catalan https://i.imgur.com/gyaAk61.png > > Wow. This really fixes the issue. I've never seen these messages before. Do > i need the debug version of KF5 to see these or just a very new version? They are only in KF >= 5.99.0. Cheers, Albert > > cheers, > Stefan > > > Cheers, > > > >Albert > >> > >> Thanks in advance. > >> > >> cheers, > >> Stefan
Re: "Configure Language" option
On 10/25/22 23:29, Albert Astals Cid wrote: El dilluns, 24 d’octubre de 2022, a les 23:38:15 (CEST), Stefan Gerlach va escriure: Hello, i noticed that several KDE apps lack the ability to switch the UI language when using the "Configure Language" dialog. The .mo files are correctly installed, all the languages are in the selection box and the configuration is saved in the klanguageoverridesrc file which is read on startup. But somehow (most of) the UI strings are shown in the system language only. I've seen this problem on Linux and Windows (macOS is probably not better) and am especially interested in making this work for LabPlot. You can also checkout Step which has the same problem. Anyone knows what may be missing or what needs to be done for this feature to work? If you have a modern KF5 there's a big set of warnings that tell you what's wrong https://invent.kde.org/education/labplot/-/merge_requests/173 After fixing that i can get labplot in Ukranian instead of my regular Catalan https://i.imgur.com/gyaAk61.png Wow. This really fixes the issue. I've never seen these messages before. Do i need the debug version of KF5 to see these or just a very new version? cheers, Stefan Cheers, Albert Thanks in advance. cheers, Stefan
Re: "Configure Language" option
El dimarts, 25 d’octubre de 2022, a les 19:49:30 (CEST), Friedrich W. H. Kossebau va escriure: > Am Dienstag, 25. Oktober 2022, 17:16:15 CEST schrieb Friedrich W. H. Kossebau: > > Am Montag, 24. Oktober 2022, 23:38:15 CEST schrieb Stefan Gerlach: > > > i noticed that several KDE apps lack the ability to switch the UI > > > language > > > when using the "Configure Language" dialog. The .mo files are correctly > > > installed, all the languages are in the selection box and the > > > configuration > > > is saved in the klanguageoverridesrc file which is read on startup. But > > > somehow (most of) the UI strings are shown in the system language only. > > On a second read I see you actually talk about the custom app language > feature. Was getting off the path here by all the other issues I saw in the > normal Step run and the rabbit holes I had to enter there :) > > Now gave that another try, with Step, given I was already warm with the > codebase, and tested by using French as custom language over my system > German. And saw that indeed some UI terms were still in German language, > despite there being a French qm file. > > Looking into the code, there might be chance for a race condition: > the custom code generated by the cmake macro ecm_create_qm_loader (from > ECMPoQmTools) uses Q_COREAPP_STARTUP_FUNCTION to hook the QTranslator > generation code for that catalog into the startup during the QApp instance > creation. > > Though the code from kxmlgui which does checking of the klanguageoverridesrc > config and then trying to adjust things by setting the LANGUAGE env var > respectively also uses Q_COREAPP_STARTUP_FUNCTION. > > So there might be some chance of race condition. And things only worked by > chance at least for the tier1 KF libraries which use that because the > registered functions are done in an order after the kxmlgui one, due to the > order of libraries that are loaded and their static data is initialized? But > then fail for anything else whose hook is executed before the kxmlgui one, > as the ecm_create_qm_loader code seems to not have any update logic? Added https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/302 Seems to work for me in step. Cheers, Albert > > As I dislike the Qt translation system personally, myself have sadly to opt > out here. Hopefully there are others with energy on that matter here. > > Cheers > Friedrich
Re: "Configure Language" option
El dilluns, 24 d’octubre de 2022, a les 23:38:15 (CEST), Stefan Gerlach va escriure: > Hello, > > i noticed that several KDE apps lack the ability to switch the UI language > when using the "Configure Language" dialog. The .mo files are correctly > installed, all the languages are in the selection box and the configuration > is saved in the klanguageoverridesrc file which is read on startup. But > somehow (most of) the UI strings are shown in the system language only. > I've seen this problem on Linux and Windows (macOS is probably not better) > and am especially interested in making this work for LabPlot. You can also > checkout Step which has the same problem. Anyone knows what may be missing > or what needs to be done for this feature to work? If you have a modern KF5 there's a big set of warnings that tell you what's wrong https://invent.kde.org/education/labplot/-/merge_requests/173 After fixing that i can get labplot in Ukranian instead of my regular Catalan https://i.imgur.com/gyaAk61.png Cheers, Albert > > Thanks in advance. > > cheers, > Stefan
KDE git repositories that will not be ported to Qt6
Hello, What is the list of KDE git repositories that will not be ported to Qt6? I guess that some of these are: frameworks/kdelibs4support, frameworks/kjs, frameworks/khtml, frameworks/kross. Thanks.
Re: Plasma Welcome Center on KDEReview
On Dienstag, 25. Oktober 2022 22:07:35 CEST Nate Graham wrote: > On 10/25/22 02:01, Ingo Klöcker wrote: > > On Montag, 24. Oktober 2022 23:16:50 CEST Nate Graham wrote: > >> Where does that YAML file live? > > > > The whole review process including the location of the YAML file is > > described at https://community.kde.org/Policies/Application_Lifecycle . > > > > I'm wondering how you manage to pass the review process seemingly without > > knowing about this page. :-) > > I know about that page, but I haven't memorized every detail of it, or > been able to always recall it as the location for the exact piece of > information I was looking for. You asked for the location of the YAML file, so I reminded you (and everybody else) where to find the location. I apologize for my tongue-in-cheek comment. Apparently, it came across the wrong way. Regards, Ingo signature.asc Description: This is a digitally signed message part.
Re: Archiving KDE Telepathy?
El dimarts, 25 d’octubre de 2022, a les 19:08:34 (CEST), Nicolas Fella va escriure: > Hi, > > there various KTP modules have seen very little development over the > last years. Most of the activity that did happen was either release > housekeeping stuff like version bumps or general code cleanup (i.e. the > kind of cleanup that some people do across the whole KDE codebase and > not necessarily out of a genuine interest in KTP). There is also no > significant activity around it on bugs.kde.org. This thing you're describing in this paragraph is exactly what maintenance is, we're not building new roads nor adding new lanes to the existing roads, but we're making sure potholes get kind of fixed. > > While certainly amazing in its vision it anecdotally never fully made > use of that potential, partly because it's just trying to solve a > problem that is really hard to solve. > > Most of the activity I see around KTP is from people trying to use it > out of curiosity but finding it broken/unpolished or not what they > expected it to be. We like to say that "Everything in KDE Gear is > maintained". I'd argue that from this follows that if it isn't actually > maintained we should drop it from the Gear releases. We are doing our > users a disservice by pretending something is maintained when it > actually isn't. We are also doing ourselves a disservice since > unpolished software "leaking" into the desktop experience is going to > make the whole product appear unpolished. > > Furthermore, with the transition to Qt6 very soon now we should make a > decision: Either we invest a non-trivial amount of work into making it > work against Qt6/KF6, or we pronounce it dead. Having it "alive" but > unported isn't helping anyone in the long term. We shipped KDE Frameworks 5 on July 2014, but we still shipped Applications using kdelibs4 until August 2017. I don't see why we would do something different with the 5 to 6 transition. > Therefore I propose that we stop releasing the various ktp- modules with > KDE Gear and archive the repositories after the last relevant KDE Gear > cycle finished. I disagree, unless you can prove it's more broken than it was when there were actual developers. Developers or new features don't count, users do count, if users can use the software there's no reason to discontinue anything. Note: I have no idea if it's broken or not, I've never used telepathy. Cheers, Albert > > Cheers > > Nico
Re: Plasma Welcome Center on KDEReview
I know about that page, but I haven't memorized every detail of it, or been able to always recall it as the location for the exact piece of information I was looking for. If you have, I'm impressed! Nate On 10/25/22 02:01, Ingo Klöcker wrote: On Montag, 24. Oktober 2022 23:16:50 CEST Nate Graham wrote: OK great, thanks! Good to notify people when doing it. :) Where does that YAML file live? The whole review process including the location of the YAML file is described at https://community.kde.org/Policies/Application_Lifecycle . I'm wondering how you manage to pass the review process seemingly without knowing about this page. :-) Regards, Ingo
Archiving KDE Telepathy?
+1
Re: "Configure Language" option
Am Dienstag, 25. Oktober 2022, 17:16:15 CEST schrieb Friedrich W. H. Kossebau: > Am Montag, 24. Oktober 2022, 23:38:15 CEST schrieb Stefan Gerlach: > > i noticed that several KDE apps lack the ability to switch the UI language > > when using the "Configure Language" dialog. The .mo files are correctly > > installed, all the languages are in the selection box and the > > configuration > > is saved in the klanguageoverridesrc file which is read on startup. But > > somehow (most of) the UI strings are shown in the system language only. On a second read I see you actually talk about the custom app language feature. Was getting off the path here by all the other issues I saw in the normal Step run and the rabbit holes I had to enter there :) Now gave that another try, with Step, given I was already warm with the codebase, and tested by using French as custom language over my system German. And saw that indeed some UI terms were still in German language, despite there being a French qm file. Looking into the code, there might be chance for a race condition: the custom code generated by the cmake macro ecm_create_qm_loader (from ECMPoQmTools) uses Q_COREAPP_STARTUP_FUNCTION to hook the QTranslator generation code for that catalog into the startup during the QApp instance creation. Though the code from kxmlgui which does checking of the klanguageoverridesrc config and then trying to adjust things by setting the LANGUAGE env var respectively also uses Q_COREAPP_STARTUP_FUNCTION. So there might be some chance of race condition. And things only worked by chance at least for the tier1 KF libraries which use that because the registered functions are done in an order after the kxmlgui one, due to the order of libraries that are loaded and their static data is initialized? But then fail for anything else whose hook is executed before the kxmlgui one, as the ecm_create_qm_loader code seems to not have any update logic? As I dislike the Qt translation system personally, myself have sadly to opt out here. Hopefully there are others with energy on that matter here. Cheers Friedrich
Re: Archiving KDE Telepathy?
+1 for the reasons you provided. Nate On 10/25/22 11:08, Nicolas Fella wrote: Hi, there various KTP modules have seen very little development over the last years. Most of the activity that did happen was either release housekeeping stuff like version bumps or general code cleanup (i.e. the kind of cleanup that some people do across the whole KDE codebase and not necessarily out of a genuine interest in KTP). There is also no significant activity around it on bugs.kde.org. While certainly amazing in its vision it anecdotally never fully made use of that potential, partly because it's just trying to solve a problem that is really hard to solve. Most of the activity I see around KTP is from people trying to use it out of curiosity but finding it broken/unpolished or not what they expected it to be. We like to say that "Everything in KDE Gear is maintained". I'd argue that from this follows that if it isn't actually maintained we should drop it from the Gear releases. We are doing our users a disservice by pretending something is maintained when it actually isn't. We are also doing ourselves a disservice since unpolished software "leaking" into the desktop experience is going to make the whole product appear unpolished. Furthermore, with the transition to Qt6 very soon now we should make a decision: Either we invest a non-trivial amount of work into making it work against Qt6/KF6, or we pronounce it dead. Having it "alive" but unported isn't helping anyone in the long term. Therefore I propose that we stop releasing the various ktp- modules with KDE Gear and archive the repositories after the last relevant KDE Gear cycle finished. Cheers Nico
Archiving KDE Telepathy?
Hi, there various KTP modules have seen very little development over the last years. Most of the activity that did happen was either release housekeeping stuff like version bumps or general code cleanup (i.e. the kind of cleanup that some people do across the whole KDE codebase and not necessarily out of a genuine interest in KTP). There is also no significant activity around it on bugs.kde.org. While certainly amazing in its vision it anecdotally never fully made use of that potential, partly because it's just trying to solve a problem that is really hard to solve. Most of the activity I see around KTP is from people trying to use it out of curiosity but finding it broken/unpolished or not what they expected it to be. We like to say that "Everything in KDE Gear is maintained". I'd argue that from this follows that if it isn't actually maintained we should drop it from the Gear releases. We are doing our users a disservice by pretending something is maintained when it actually isn't. We are also doing ourselves a disservice since unpolished software "leaking" into the desktop experience is going to make the whole product appear unpolished. Furthermore, with the transition to Qt6 very soon now we should make a decision: Either we invest a non-trivial amount of work into making it work against Qt6/KF6, or we pronounce it dead. Having it "alive" but unported isn't helping anyone in the long term. Therefore I propose that we stop releasing the various ktp- modules with KDE Gear and archive the repositories after the last relevant KDE Gear cycle finished. Cheers Nico
Re: "Configure Language" option
Am Montag, 24. Oktober 2022, 23:38:15 CEST schrieb Stefan Gerlach: > i noticed that several KDE apps lack the ability to switch the UI language > when using the "Configure Language" dialog. The .mo files are correctly > installed, all the languages are in the selection box and the configuration > is saved in the klanguageoverridesrc file which is read on startup. But > somehow (most of) the UI strings are shown in the system language only. > I've seen this problem on Linux and Windows (macOS is probably not better) > and am especially interested in making this work for LabPlot. You can also > checkout Step which has the same problem. Anyone knows what may be missing > or what needs to be done for this feature to work? No idea about LabPlot, but you made me look at Step as I had done something else to it before (not a maintainer though), and that resulted in these kind of fixes https://invent.kde.org/education/step/-/merge_requests/12 (merged) https://invent.kde.org/education/step/-/merge_requests/13 (review needed ATM) https://invent.kde.org/education/step/-/merge_requests/14 (review needed ATM) Can you give exact examples of what UI strings where in LabPlot you see not translated (and which locale tested with)? And which other apps in "several KDE apps" are there that need care? Cheers Friedrich
Re: Gitlab update, 2FA now mandatory
On Sunday, 23 October, 2022 12:02:23 PM IST Ben Cooksley wrote: > I > have also enabled Mandatory 2FA, which Gitlab will ask you to configure > next time you access it. Is the 2FA in KDE identity website same as this. The KDE identity shows a grid based system where you combine the grid and your password for 2FA. I have also already enabled 2FA for KDE identity with totp, does this supersede it? -- Raghavendra Kamath emblik.studio
Re: Plasma Welcome Center on KDEReview
On Montag, 24. Oktober 2022 23:16:50 CEST Nate Graham wrote: > OK great, thanks! Good to notify people when doing it. :) > > Where does that YAML file live? The whole review process including the location of the YAML file is described at https://community.kde.org/Policies/Application_Lifecycle . I'm wondering how you manage to pass the review process seemingly without knowing about this page. :-) Regards, Ingo signature.asc Description: This is a digitally signed message part.
