If you fix the naming or the summary, please remember to only touch the original English message, not the translations, which are handled differently (or your merge request won't be able to be merged).

Moved to gitlab. Unfortunately a spammy user disrupted the status.

https://invent.kde.org/system/khelpcenter/-/merge_requests/25 committed to the kf6 branch.

Laurent kindly took over this, extended and updated this as part of https://invent.kde.org/system/khelpcenter/-/merge_requests/25 (see https://invent.kde.org/system/khelpcenter/-/merge_requests/25/diffs?commit_id=f6d308672a9f68c20585f5d05b6c6032355f850a ) and it was merged in the kf6 branch. This review can be closed.

Resolved long time ago, cleaning up the task.

Solved long time ago, just closing for cleanup

As we moved away from phabricator (to gitlab) for code reviews, this is no more relevant.

Sorry, wrong copy-and-paste: T16059

Please leave them there for now. See T16036.

The ticket can't be closed just yet: the new documentation is stated to be CC BY SA 4.0 but the text is mostly the same as the old one, which is GFDL 1.2. Unless a proper relicensing is documented, where all contributors agree (or have already agreed though FLA and or https://invent.kde.org/sdk/kde-dev-scripts/-/blob/master/relicensecheck.pl), the license must stay GFDL 1.2.

In T16036#285444, @cgilles wrote:

Same - if you start from the StaticMessages.sh script from the other repositories, it should be fine.

That discussion mentioned the renaming of the files (see also https://invent.kde.org/sysadmin/l10n-scripty/-/issues/2 ) but I don't remember any final decision about that - maybe we should follow up up on that instead?

https://invent.kde.org/sysadmin/repo-metadata/-/commit/57b8388a66685e42f1fb23f1f3b32939e6d7b7b4

I agree with Carl's feedback - just note that "add rst" or other formats is not so straightforward as it may seems.

In T15621#280077, @Nowshed wrote:

As other users have mentioned, the solved part is not actually solved. The main git based documentation is kind of stalled.

Improving the documentation is a good idea, but please consider there are two types of documentation:

• developer documentation
• user facing documentation (application manuals)

+1 of course

Ok, so I do have a last minute objections.
This would be the only reference to "workers" in the repository names.

I've adapted scripty to handle this:

• trunk (current master): renamed the directory and the _desktop_ file (which is linked to the repository name)
• current stable branch (still tracking Gear 22.04): disabled the extraction https://invent.kde.org/sysadmin/l10n-scripty/commit/3c672a22d6e9280362db2ee46847159ae54e25e3 The change doesn't affect that branch, and next week we will branch Gear 22.08, so those files will be saved and go away.

For the record, the repository used to hold more kio modules, but they were obsoleted until only perldoc is left right now.

From the last KF6 meeting, it looks like:

• the usage of emoji is being implemented as part of the locale work (see T12429 )
• the last part of the discussion is about implementing real artwork, but there is nothing which blocks KF6, so I'm going to move this to backlog.

According the discussion, there seems to be no action item from this. The porting of the language listing is tracked by T12429 as already mentioned. I'm going to close this, feel free to reopen it if needed.

(post KF6 meeting 2021-05-22): there is a solid plan in motion, moving to "in progress" on the KF6 board (no real blockers for the release).

(post KF6 meeting 2021-05-22): this specific ticket is done, the two use cases have been fixed.

Just in case, this is the thing I'm working on, but it's still heavily WIP, especially the injector interface (something is already working with the example legacy extractor):
https://invent.kde.org/ltoscano/noktra/

Notes from the KF6 sprint (2021-03-27):

Ups, sorry, I've missed that. Going to close this one.

In T14079#249883, @echarruau wrote:

Images must be located within the invent.kde.org domain.
For GCompris a first attempt to add screenshots failed, running validators gave the following results:

docker run -i italia/publiccode-parser-go https://invent.kde.org/education/gcompris/-/raw/master/publiccode.yml
validation ko:
description/en/screenshots: Absolute URL (https://gcompris.net/screenshots_qt/large/root.png) is outside the repository (https://invent.kde.org/education/gcompris/-/raw/master/)
description/it/screenshots: Absolute URL (https://gcompris.net/screenshots_qt/large/root.png) is outside the repository (https://invent.kde.org/education/gcompris/-/raw/master/)

In T14079#249886, @echarruau wrote:

In T14079#249704, @ognarb wrote:

In T14079#249703, @yuri wrote:

As new italian citizen, I can give a hand for this project.

I have begun with Okular, Merge Request will be submited soon (today). It's a little fastidious to do, especially when you know nothing of the project. So I have used .desktop file and Okular site as information source, may be that can be automated (appstream ?), at least for the minimal version.

If needed and someone provides me an example, I could look into making apps.kde.org generate these files for us :)

There is already an online page to generate publiccode.yml:
https://publiccode-editor.developers.italia.it/

In T14079#249885, @echarruau wrote:

In T14079#249846, @yuri wrote:

As you can see, my Merge Request was commented by the maintainers, theirs concerns are :

• the scope available is limitative
• they don't want to have theirs name or email published into public code catalogue
• they want it automated :)
  
  I'm also new at KDE, and honestly I don't figure out what next steps can be....

Hi Yuri,
Could we simply not replace the name by Okular maintainers something like:

maintenance:

type: community
contacts:
  - name: okular maintainers
    email: support@okular.net

if okular has a support email obviously.

This is something you can ask to the catalog maintainer.

In T14079#249713, @timotheegiet wrote:

Note, apparently the screenshots need to be fetched from the source repository (see https://github.com/italia/developers-italia-backend/issues/212 ).

In T13618#240765, @aacid wrote:

kdeedu-data ktuberling khangman are blocked by sr magicly shared cmake file cmake_modules/srDataMacros.cmake

Any idea how to proceed with it?

I guess we need to continue with this. I was told LFS works on our repositories, so at least we could resume this when there are no other blockers.

In T14091#249275, @ngraham wrote:

I agree with Leinir and I also don't really understand why there's a controversy here. We can forget about the release service itself; the apps it releases all have a predictable 4-month release cycle. Can't we go back, as Leinir suggested, to doing a release announcement each time these apps have a major release?

Please note I'm working on base replacement in python too.
The idea is to have something modular (starting from an independent translation extraction application which may be used elsewhere). I plan to share something before that deadline.

This is about the promo announcement. Changing the version number to accommodate a promo messaging is going a bit far.
Some applications won't be under any unified schema anyway. Without mentioning krita which will probably have its own announcement, there are several others which won't and don't need to be released together. Or do you want to include krita releases as well? Then the unified versioning doesn't work anyway.
Also, in 3 months there may be several (sub)releases.

In T11933#247540, @paulb wrote:

In T11933#247538, @aacid wrote:

1. If we do a release every month i don't understand why an announcement every month is not ideal.

Read back the prior comments. We have already explained this.

We had that before too and according to you it wasn't a problem?

It has always been problematic. The change in periodicity and the debranding led to a nosedive in popularity of the announcements. Again, we have already explained this.

In T11933#247531, @ngraham wrote:

Fair, but really, do we care about that?

Yes.

Btw, when I originally discussed the issues with "KDE Applications" one of proposals was just to find a new, totally unrelated name for the bundle which wasn't made of "App", "applications" or any other generic word hard to distinguish.

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!"

Btw, when I originally discussed the issues with "KDE Applications" one of proposals was just to find a new, totally unrelated name for the bundle which wasn't made of "App", "applications" or any other generic word hard to distinguish.

The new format doesn't seem to work, I agree. Just please don't go back to "let's release KDE", which has strong implication on the image of the community, and I believe can't be decided by promo alone.
Same for release all all applications together: what is the line?

In T11070#247315, @sanecito wrote:

Translations in the repositories would make the life of people who touches several repositories almost impossible, so it's out of the question.
The solution is to make weblate work with a structure which fits us (either svn or per-language git repositories).

I'm really sorry for the delay, and thanks for the help!

Also, if there is just one author, maybe we could just commit the change using the proper authorship information.

I think we should remember to report all the authors in the commit messages when importing the content.

• autocorrect: we need to find (separate issue) where those files should live (probably the last leftover from the kdelibs split)
• step files are probably not needed anymore, as the object info messages are now handled through po files (see step_objinfo_files.pot)

I suggest everyone (and I literally mean everyone) stops commenting on this ticket for 48 hours.

In T11070#238095, @subins2000 wrote:

Just a quick note: we can't and won't ever enable any automatic acceptance of strings.
It would like allowing automatic merging of code from people without commit permissions, and this is not allowed.
The final decision about the validity of a string must be done by someone with commit access.

I already wrote it: a central place is needed so that

• people *NOT* using weblate don't have to checkout tons of repositories to contribute. That's enough in itself.
• we may use posummit even with weblate to provide a single branch to everyone, which means that some logic to inject the translations to each branch will be needed somewhere else
• it will be the only interface that weblate would have to deal with (because in 5 years we may change again tool, and we don't lose the history)
• even in the case were part of the web tool would be the central place, still that would be the reference point, not the content of each repository which would be a mirror once we solve T12268.

Is there some other reference where it is described, why this will make things "much harder for the translators"? Basically you would in fact have one central location for all files, but per project. Ideally those could get summarized at a different place like Weblate maybe, so there is still a fast overview of all projects and languages needing attention for example. Not sure whether that is supported by Weblate, though.