In T11070#230949, @slavekb wrote:

In T11070#230948, @ltoscano wrote:

I agree it's useful when you don't have tooling for it, but as I said, this (update POs with newer POTs) should happen and will continue to happen outside weblate (or any other such tool).

It's not that we don't have the tools to do that. But it's about the fact that we wanted it that way.

We have a tool to update the POT files in the master branch, where about updating the PO, we want Weblate to take care of it – simply because we have decided that Weblate should be authoritative for PO files.

In T11070#230947, @slavekb wrote:

In T11070#230929, @ltoscano wrote:

As I mentioned – POT files are updated externally and are pushed into the GIT, as the unique place to which they belong.

Weblate then automatically takes care of updating PO files according to templates. There probably does not give much reason for this step to be solved by each team individually / manually. Therefore, it seems like a good idea when this is done automatically in Weblate.

Just for the record: our current automation already does it (for the last 15+ years).

Sure, I had no doubt that this is already automated. With such a volume of translations, it is not possible otherwise.

Updating PO files by POT is basically a mechanical operation, so there can be a useful one when Weblate does this, as a central place to manage PO files, because during that, it can do merges with currently pending translations.

In T11070#230944, @slavekb wrote:

In T11070#230929, @ltoscano wrote:

As I mentioned – POT files are updated externally and are pushed into the GIT, as the unique place to which they belong.

Weblate then automatically takes care of updating PO files according to templates. There probably does not give much reason for this step to be solved by each team individually / manually. Therefore, it seems like a good idea when this is done automatically in Weblate.

In T11070#230928, @slavekb wrote:

In T11070#230898, @ltoscano wrote:

In T11070#230894, @slavekb wrote:

If you find it useful, I can mention the experience of using Weblate for a project that is very similar to the scope of translations – Trinity Desktop Environment – see TDE Weblate.

It's a tool people are very aware of, and probably one of the best candidate. That said, it's not just "install and it magically integrates in the existing infrastructure". Which again, does *not* mean it won't
be implemented.

Yes, of course, it doesn't solve integration by waving a magic wand – it takes effort. However, it can be beneficial for process automation.

For example, for TDE:

PO file management is now the sole responsibility of TDE Weblate. Outside TDE Weblate is an automated update of POT files that are pushed into TDE Gitea. Thanks to the webhook, an update is triggered in the TDE Weblate. And TDE Weblate will update each PO file, which is pushed back into TDE Gitea.

In T11070#230899, @frederico wrote:

And I have another fear: bad translations. Some people said to our translation group that would be interesting that Lokalize include a tool to use Google Translator, for example. And I work on some translation on Transifex and saw terrible translations, clearly result of using automatic translations. One tremendous problem that we had was with Rocs. In Brazilian Portuguese, we translate "graph" in two different ways: when it's about graph theory, we use "grafo" and when is graph as charts, we use "gráfico". Well, someone translated all "graph" in Rocs as "gráfico" and not "grafo". You can imagine the problem of it, specially because this is an educational tool... And I won't even talk about consistency problems, of terms translated differently in the same package.

In T11070#230894, @slavekb wrote:

If you find it useful, I can mention the experience of using Weblate for a project that is very similar to the scope of translations – Trinity Desktop Environment – see TDE Weblate.

In T11070#230883, @kucharczyk wrote:

In T11070#230868, @ltoscano wrote:

Again and again. No one is AGAINST this change. It requires some other steps first, and then it will arrive.

Trying to hold onto SVN is literally one such example where it prevents the whole thing from moving forward.

In T11070#230866, @kucharczyk wrote:

I strongly urge everyone who is against any changes to reconsider because I would like to see the translation side of KDE prosper instead of becoming a complete fossil.

I believe a few sentences in the the commit message contradicts each other.

In D29711#670470, @ngraham wrote:

In D29711#670458, @cfeck wrote:

Sorry if I don't understand the scope, but does this mean I am forced to install systemsettings to be able to use KCMs?

Why, is the "I'm using Plasma but I don't have System Settings installed" use case something that you think we should handle?

The context is that users were requesting for KCMs to be opened in System Settings, not KCMShell (https://bugs.kde.org/show_bug.cgi?id=402790) and we implemented that for the KCM runner for Plasma 5.19. The issue fixed here is an inconsistency in that opening KCMs from Plasma applet context menu would still open it in KCMShell, not System Settings or Info Center (which in 5.19 is now just System Settings; the same app shows both).

Please don't update the dates manually, for various reasons:

• replacing the old version means losing the old versions are lost;
• the version is updated in a centralized way; see for example: https://commits.kde.org/okular/3d148bd57053460bea8bca29a87e97c3f1266481/ or https://commits.kde.org/gwenview/0ccc0c2fc00176da9064999f997654c9e1624ef5
• the date is incorrect; 2020-05-11 is the tagging date, the release date is 2020-05-14.

Adding a few more details to make it easier to decide on the localization side:

• Plasma 5.18 is the new LTS
• its next releases (5.18.6) is currently planned for September 17th, 2020.

Technically kcm should be called kcm<Plasma_version>_<name>. So far the Plasma_version part has been ignored, but at least kcm_ should be there.

In D29575#667175, @winterz wrote:

I'm guessing it's ok to depend on K5I18N ?

Just please patch Messages.sh to rename the file, I will take care of moving it.