Anecdotal evidence, when setting up the booth, someone asked "how much are the konquis" and they said "that's quite cheap" when told 15€
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Feb 6 2024
Jan 8 2024
Dec 13 2022
Personally i know 0 about how that works, but if you're doing the same as the two other places, i don't see why it wouldn't work.
Yes, https://invent.kde.org/sysadmin/l10n-scripty/-/issues/2 is the solution that makes sense to me (but on the other hand i made that issue so that's not a surprise)
Oct 26 2022
I'll ask the other Board folks if this would be permissible, and for other details.
Oct 18 2022
autocorrect moved to calligra were at least it's being used https://invent.kde.org/office/calligra/commit/c6c6c899a3b640555df551d96d0668bb16ae0042
Oct 17 2022
Oct 12 2022
khangman did not have any kvtml file
https://websvn.kde.org/trunk/l10n-kf5/nn/data/khangman/khangman/?pathrev=1605218
Oct 10 2022
Jul 6 2022
There's some adaptation in the release scripts and translation structure needed, but nothing insurmountable.
Jun 13 2022
May 30 2022
autocorrect is a PAIN because it's used by both pimcommon and calligra, so were do we put it? Currently we're not putting it anywhere so it's not being even used ^_^
May 25 2022
May 22 2022
I've removed the kturtle data, it was all for a very old version of kturtle, the new version of kturtle doesn't support those data files
Mar 26 2022
In T15408#273244, @nicolasfella wrote:In the title, did you mean "... of Qt5 work with lconvert of Qt6"?
Mar 25 2022
Feb 21 2022
That's probably acceptable but I am going to maybe wrongly assume you don't also speak Hebrew?
I'm going to warn you against that, you can't create a system to automatically commit things from other people into KDE servers without human interaction, that's basically giving out your user for anyone else to [ab]use, and that's obviously not allowed.
Jan 24 2022
Please subscribe to the mailing list and discuss there, i want to let phabricator die as soon as possible.
Nov 29 2021
Jun 27 2021
In T14633#259271, @paulb wrote:@aacid: can we use that text for other people?
Jun 26 2021
In T14633#258952, @lydia wrote:Do we have a text or link explaining what we want so that everyone can reuse that when reaching out?
Albert to reach out to: coolo, dmueler, waba, torbenweiss
In T14633#259024, @paulb wrote:I think it was it @apol the person who had contacts in the Alba Syncrotron.
Jun 24 2021
Another potential solution is using litehtml/qlitehtml that seems to know how to paint to a qpainter and would solve the reason for which we can't move to qwebengine for example
Exactly, QJSEngine::setInterrupted really seems like one can hook a qtimer from another thread to stop it, so that is the last missing feature from KJS as far as i can see.
Apr 22 2021
To change the culture of KDE to take control of shipping out apps into stores we need to integrate app store packaging with app repos and release tools.
The release tools need to bump up the version numbers same as they do for appstream and cmake files.
Mar 14 2021
Feb 17 2021
Ah i see that @stikonas had already mentioned it, sorry for the noise ^_^
Isn't KLanguageName what you want? https://api.kde.org/frameworks/kconfigwidgets/html/klanguagename_8h_source.html
Feb 7 2021
That's also an option, simply remove the need for it 👍
The only way i can think of is, make it more generic, make it not use perl and move it to ecm
Jan 5 2021
In T11933#247596, @xyquadrat wrote:To chime in as well:
To my knowledge, this is the situation we have:
- We have a collection of software that is released on a 4-month-schedule. We currently call this the Release Service
In T11933#247583, @paulb wrote:To re-steer the conversation:
We would like to do a bigger announcement for the general public every 3 or 4 months (instead of monthly) containing the highlights of all the most exciting changes users can look forward to in applications (and other stuff where applicable) when they hit their distros repos/the app stores they are using.
Jan 4 2021
- If we do a release every month i don't understand why an announcement every month is not ideal. We had that before too and according to you it wasn't a problem?
- "just call it for what it is" yeah ok, "what is it?"
- "We have often been saddled with less than optimal names because someone has fixated on them before consulting with us and it has made things so much more difficult marketing-wise." Can you give some examples?
I don't see how we can come up with a word for a bundle of applications that doesn't include the word applications in it. But I'm bad at naming things; maybe someone else can come yup something something good. Ooh, how about some kind of Web 3.0 name like "Plarq". Just imagine: "KDE announces the release of Plarq 21.04!"
"we tried it, it didn't work, we want back to what we were doing before"
Jan 3 2021
We are losing readers
Dec 19 2020
ognarb is Carl ;)
Dec 15 2020
It is not fair to say that you got no answer, i answered you.
Dec 1 2020
Yeah, i guess it can be considered semi standard.
Nov 30 2020
Or even maybe add the action to KStandardAction, given that you need to hook it up manually either way?
In T12200#245725, @mart wrote:As background, back in the last KF6 sprint (december 2019, before the world ended) it was done a big review of each framework in order to untangle the dependency tree as much as possible (and remove dependencies between frameworks, if possible making them rise in tiers. (this task is part of the kf6 workboard)
The main think keeping this framework dependent from KXmlGui (and most of its dependencies in turn is KActionCollection, so there was decided to try to get rid of that dependency.
Nov 28 2020
I don't understand why you say this is a weird method, it's exactly what the KStandardAction methods so, and they're used *everywhere*
except the little icon we set in the action, so it makes little sense to share ;)
Can someone give me a rationale for this?
Oct 25 2020
Looks good to me.
Shouldn't the
if entry.msgid == msgid:
now also have some kind of msgctxt checking?
Oct 24 2020
chmk Not happening for 20.12, maybe 21.04, and even if it doesn, i don't see a reason to drop chm support from okular until KF6-okular
Sep 19 2020
kajongg only has german voices https://invent.kde.org/games/kajongg/-/merge_requests/2
kdeedu-data ktuberling khangman are blocked by sr magicly shared cmake file cmake_modules/srDataMacros.cmake
You're right about the step files, just removed them
Sep 13 2020
Sep 8 2020
I have been mostly doing this without knowing this task existed, but to be real, i disagree with killing KRandom, what needs killing is KRandom::random which is already deprecated
Do we need need need libkvkontakte? Seems it's not really used a lot https://www.archlinux.org/packages/extra/x86_64/libkvkontakte/
As i mentioned on the part task, this is not possible at this point
If we don't keep KJS we're probably end up copying it inside Okular since it's the only Qt JS engine that supports the "please break after N seconds", since we need to make sure people don't put an infinite loop JS in PDF files
Aug 23 2020
In that case I have to say that many users maybe just want to quickly correct some Strings for their application that they use.
Aug 21 2020
In T11070#237886, @dkazakov wrote:In T11070#237855, @clel wrote:What modern tools are you talking about? Is this some online tool, some commandline tool or something else? Can you reference some example for such tool?
Well, I'm not a translator. I just wanted to add a requirement to the list.
Aug 19 2020
In T13514#237735, @rempt wrote:Just to show the other side of the argument, i've had lots of developers asking for scripty not to commit to the repo the .desktop translations back to the repos since it creates merge conflicts for them.
That is not "another side of the argument". It's irrelevant, because .desktop files are edited by developers, po files would only be copied in.
In T13514#237706, @rempt wrote:In T13514#237638, @huftis wrote:This will make things easier for developers, packagers and user’s who like to compile applications themselves (instead of using packages, or just for testing a new feature or a bug fix).
And it follows the most common practice across the free software world, too, so there's familiarity for contributors, too.
But having a non-central location of the PO files will make things much harder for the translators (for various reasons that I won’t get into now).
May we have the best of both worlds? That is, have a central repository for translations, for use by the translators, and automatic copying of the translations into each application’s repository by scripty. Basically the same thing that happens with translations in .desktop files. They are translated centrally, but any updates to the .po files are merged into the .desktop files in each application’s repository by scripty each night. Having a similar thing be done with the .po files would be nice. Plain .po files would be copied directly, while other formats (e.g., .ts files used by some Qt applications) would be converted from the .po files.
And to avoid anyone manually editing the ‘.po’ files in a an applications repository, perhaps a pre-commit hook could be added so that only scripty is allowed to commit changes to the files.
Well, that would be a huge improvement for sure.
In T13514#237695, @dkazakov wrote:In T13514#237630, @rempt wrote:[...] to include the po files in the source repositories, for the following reasons:
In T13514#237630, @rempt wrote:This will make things easier for developers, packagers and user’s who like to compile applications themselves (instead of using packages, or just for testing a new feature or a bug fix).
But having a non-central location of the PO files will make things much harder for the translators (for various reasons that I won’t get into now).Can it be solved with git-submodules? It looks like submodules were invented exactly for this purpose, weren't they?
TBH I'm mostly ignoring this task, but i'm at least going to answer your initial points
Aug 17 2020
In T13514#237616, @ltoscano wrote:In T13514#237615, @dkazakov wrote:I strongly believe that people who need easy review needs something like weblate. All the others don't care whether it's direct git pushing or svn pushing.
Well, the main problem (in Krita) that newcomers are frightened away from doing translations because of too complicated process. Any solution that would make it simpler would work.
So we are basically in agreement, but not on having a git-based translation system directly exposed to the newcomers. That would make just things more complicated.
PS
Though SVN was actually the reason why my students didn't want to do the translations. It is too outdated and noone knows how to use it anymore.That's sad, but I have to say that no one want to use it, because it's documented, and the basic commands maps directly to git commands (clone/checkout, commit+push/commit - even one less).
This does *not* mean I want to keep it, but I feel there is a bit too much bad advertisement.
Jul 12 2020
If everyone is really happy about that, please remember to commit it to the release/20.08 branch first and then mege to master.
Jul 3 2020
I feel like it would be a good moment to pick up this again, @ltoscano what do you think?
Jun 24 2020
In D21277#675639, @gregormi wrote:Hmm, arc land says...
FETCH Fetching origin/master... fatal: unable to update url base from redirection: asked for: https://git@invent.kde.org/kmines/info/refs?service=git-upload-pack redirect: https://invent.kde.org/users/sign_in Usage Exception: Fetch failed! Fix the error and run "arc land" again.What can I do now? Except a new merge request on https://invent.kde.org/games/kmines?
Any special reason it's called "No. 2"? Is there a No 1 somewhere?
Yes :) - No. 1 is a slightly modified version of my original proposal, which I uploaded here: https://www.pling.com/p/1397003/.
Ok, i guess you can commit it.
Jun 18 2020
Jun 17 2020
Jun 16 2020
Jun 13 2020
In D26342#675164, @sdepiets wrote:In D26342#675142, @dfaure wrote:This actually breaks language auto-detection for me in the KMail composer.
Testcase:
- New Mail
- I type "Bonjour," in the body
Before: It's detected as French and not underlined as a typo
After: The language remains English, and the word is underlined as a typo
Workaround: Tools / Spelling / change language from English to French
Too bad I'm realizing this is the reason for the regression only today (day of 5.71 release) by looking at the KF-5.71 changelog :(I don't think that's a regression, in the previous behavior you could try to set any language to proofread, it would always auto-detect "Bonjour" as French, thus the "Tools / Spelling / change language" had not effect if autodetect was enabled at system level (while autodetection should be an application or even case by case decision).
It may not seem like an issue for simple cases, but actually for mixed contents (i.e. an email that is 50% French, 50% English) that would be detected as English, you would have no way at all to check the French text without disabling system-wide autodectection.
Calling setAutoDetectLanguageDisabled(false) restores the previous behavior
Given the current state of instability we have due to the gitlab migration + different structure fallout, let's give us a few weeks to try to stabilize things and come back to this?