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.

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#230868, @ltoscano wrote:

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

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.

Not to spread any FUD but I have taken a look at the state of the Czech translation and it does not look good.

In T11093#226352, @niccolove wrote:

Ah, sorry for that mistake. The fourth one is Vvave. Amarok declared was unmaintained after me writing this task (although I got a mail from the developer claiming that the porting to qt5 is 'almost done'). Regarding juk as a music management, I have to look more into it.

Ah, sorry for that mistake. The fourth one is Vvave. Amarok declared was unmaintained after me writing this task (although I got a mail from the developer claiming that the porting to qt5 is 'almost done'). Regarding juk as a music management, I have to look more into it.

Music applications. Currently, KDE has four of them: Amarok, Elisa, JuK and Elisa.

That confuses me. I read that Amarok is unmaintained (well, it is still using Qt4 and KDElibs...), JuK is more a music management application than a music player.

In T11074#203505, @KonqiDragon wrote:

I before wrote (T11220: Format option) about a simplified USB formating option, when you can will easily format the USB drive from File manager like in Windows, Linux Mint and Deepin.

I don't know if this could be a priority as part of the user experience simplification, but when I first tried the Linux, i couldn't understand how to format my flash drive, so it's important to me personally.

In T11074#203509, @chempfling wrote:

In T11074#203505, @KonqiDragon wrote:

I before wrote (T11220: Format option) about a simplified USB formating option, when you can will easily format the USB drive from File manager like in Windows, Linux Mint and Deepin.

I don't know if this could be a priority as part of the user experience simplification, but when I first tried the Linux, i couldn't understand how to format my flash drive, so it's important to me personally.

Sounds great, but maybe the wrong threat? i cannot bring flash formatting and accessibility together in my mint somehow. Maybe can you explain?

In T11074#203505, @KonqiDragon wrote:

I before wrote (T11220: Format option) about a simplified USB formating option, when you can will easily format the USB drive from File manager like in Windows, Linux Mint and Deepin.

I don't know if this could be a priority as part of the user experience simplification, but when I first tried the Linux, i couldn't understand how to format my flash drive, so it's important to me personally.

I before wrote (T11220: Format option) about a simplified USB formating option, when you can will easily format the USB drive from File manager like in Windows, Linux Mint and Deepin.

This bug might be relevant to this goal: Kimpanel icon size is different from system tray icons.

https://autoconfig.kde.org/discover/ Process to curate Discover featured apps

In T11093#199130, @ndavis wrote:

In general, we use labels for everything that isn't a common control. Common controls are things like forward, back, undo, redo, etc. If a label isn't used, the function of the button needs to be pretty obvious.

I think it's more important to be consistent in logic than uniform in appearance. There is a lot of overlap between the two, but there are cases where aiming for a uniform appearance leads to inflexible designs that make some UIs less usable.

Oh yea, we will for sure towards improving the accessibility. This is very needed at this point :).
if others here want to help and pick up some accessibility related tasks (what often goes hand in hand with usability, as it also means you can use the desktop with eyboard only), just assign to the accessibility mailing list and join us :).
We are happy for any helping hand and it would be coold to fom a real accessibility team.

In T11093#199099, @onvitaik wrote:

Here's my 2 cents:

I think toolbars themselves are also inconsistent. Some icons will be followed by text, while some will not, and some icon-only buttons are also mixed with icon+text buttons. you can see, for example, here and here how that mixing happens.

Taking two other DEs as reference, their toolbars are usually only icons, icons with text, or just text, all with minimal mixing. The result is a uniform, consistent look, which makes them look really pleasing to the eyes. Examples: Gnome, MacOS.

In case of icon-only toolbars, tooltips on mouse over or a button press could give a description of the button's purpose. Having intuitive buttons for each action would be the ideal, though, as you'd be able to ditch the text, keep the toolbars compact, and free up space for more actions.

Here's my 2 cents:

In T11070#198447, @ltoscano wrote:

In T11070#198431, @guoyunhe wrote:

In T11070#198422, @ltoscano wrote:

One of the requirement is to allow people to still do changes on SVN. If I, as administrator, need to directly change a po file (for several languages), I must be able to do it, and the online translation tool should cope with that.

Can you give a more detailed description of what kind of change you need to do with po files? When the context is clear, we can support it in the Weblate workflow.

Any kind of change in both strings (for example, fixing mistakes in tags which prevent the po file - from documentation - from being compiled) and headers (license details, missing tags, etc). And also renaming of files, and other operations that are probably not problematic from this workflow (copy with a different name and removal).

In T11070#198442, @ltoscano wrote:

How does manage the case when a file is renamed but there are new proposed translations for it? Does crowdin recognize the rename and reassign the pending changes?

In T11070#198431, @guoyunhe wrote:

In T11070#198422, @ltoscano wrote:

One of the requirement is to allow people to still do changes on SVN. If I, as administrator, need to directly change a po file (for several languages), I must be able to do it, and the online translation tool should cope with that.

Can you give a more detailed description of what kind of change you need to do with po files? When the context is clear, we can support it in the Weblate workflow.

In T11070#198432, @ppeter wrote:

In T11070#198422, @ltoscano wrote:

In T11070#198415, @ppeter wrote:

In T11070#198391, @aacid wrote:

still allow people to manage translations in SVN, but it will be announced that it is being deprecated.

NO we are NOT deprecating SVN in any way, that is not acceptable.

No... It means that submit PO file to SVN is unacceptable after migrated to Weblate to prevent the conflict issues, I don't really want to deprecate SVN completely.

It would mean deprecating SVN.

One of the requirement is to allow people to still do changes on SVN. If I, as administrator, need to directly change a po file (for several languages), I must be able to do it, and the online translation tool should cope with that.

Oh... See https://phabricator.kde.org/T11070#198374 FAQ 2.

In T11070#198425, @guoyunhe wrote:

SVN submit and Weblate can work together. I have made a workflow with SVN+Crowdin. New translation submitted to SVN will also be uploaded to Crowdin. So both Lokalize and Weblate/Crowdin lovers can still contribute in their preferred way. This is totally possible.

Here is my script for Crowdin workflow, should be similar with Weblate: https://github.com/KDE-China/crowdin/blob/master/upload_translations

In T11070#198422, @ltoscano wrote:

In T11070#198415, @ppeter wrote:

In T11070#198391, @aacid wrote:

still allow people to manage translations in SVN, but it will be announced that it is being deprecated.

NO we are NOT deprecating SVN in any way, that is not acceptable.

No... It means that submit PO file to SVN is unacceptable after migrated to Weblate to prevent the conflict issues, I don't really want to deprecate SVN completely.

It would mean deprecating SVN.

One of the requirement is to allow people to still do changes on SVN. If I, as administrator, need to directly change a po file (for several languages), I must be able to do it, and the online translation tool should cope with that.

In T11070#198422, @ltoscano wrote:

One of the requirement is to allow people to still do changes on SVN. If I, as administrator, need to directly change a po file (for several languages), I must be able to do it, and the online translation tool should cope with that.

SVN submit and Weblate can work together. I have made a workflow with SVN+Crowdin. New translation submitted to SVN will also be uploaded to Crowdin. So both Lokalize and Weblate/Crowdin lovers can still contribute in their preferred way. This is totally possible.

Do you have an alternative then to the current problem of reducing barrier to contribute @ppeter ? Forgive my ignorance, but it's possible for Weblate and Git PR's to co-exist so I don't see why it wouldn't be possible for Weblate and SVN to co-exist to appease both sides.

In T11070#198422, @ltoscano wrote:

In T11070#198415, @ppeter wrote:

In T11070#198391, @aacid wrote:

still allow people to manage translations in SVN, but it will be announced that it is being deprecated.

NO we are NOT deprecating SVN in any way, that is not acceptable.

No... It means that submit PO file to SVN is unacceptable after migrated to Weblate to prevent the conflict issues, I don't really want to deprecate SVN completely.

It would mean deprecating SVN.

One of the requirement is to allow people to still do changes on SVN. If I, as administrator, need to directly change a po file (for several languages), I must be able to do it, and the online translation tool should cope with that.

In T11070#198415, @ppeter wrote:

In T11070#198391, @aacid wrote:

still allow people to manage translations in SVN, but it will be announced that it is being deprecated.

NO we are NOT deprecating SVN in any way, that is not acceptable.

No... It means that submit PO file to SVN is unacceptable after migrated to Weblate to prevent the conflict issues, I don't really want to deprecate SVN completely.

In T11070#198391, @aacid wrote:

still allow people to manage translations in SVN, but it will be announced that it is being deprecated.

NO we are NOT deprecating SVN in any way, that is not acceptable.

Thanks! I do think that we will work towards better accessibility independent of this. I think we'll have the support of many other developers, but sadly accessibility is not the most mainstream topic. I do intend to meet up with at least @chempfling some time soon (sadly I end up being busy way too often).
I think it was a good exercise to formulate the goal in any case and I think we'll continue to influence other developers to make good choices for all users :)

still allow people to manage translations in SVN, but it will be announced that it is being deprecated.

In T11070#198379, @ppeter wrote:

And no, even if we had a KDE online translation tool (whose timing is not yet clear at this point), the Qt project won't and should not use it.

In T11070#198380, @ppeter wrote:

And if it is approved, could I open a JIRA task to Qt for migrating their translation platform to KDE's weblate due to the reason @meskobalazs said? @ltoscano

I am also a Qt translator and I also wanna let Qt localization easier.

And if it is approved, could I open a JIRA task to Qt for migrating their translation platform to KDE's weblate due to the reason @meskobalazs said? @ltoscano

In T11070#198378, @ltoscano wrote:

In T11070#198376, @ppeter wrote:

In T11070#198358, @ltoscano wrote:

I mentioned it elsewhere, but before doing this, it should be clear how much the changes made to the underlying repository (file rename, file changes which do not pass through the online tool) impact the online tool.
Also, I'd personally invest more time into preparation work which would reduce the amount of changes that may break the strings, like for example:

• flattening the directory structure removing the modules (so <lang>/messages/<repository>/<po_file> instead of <lang>/messages/<module>/<po_file>
• a mechanism to detect file renames and magically handles them
• move everyone to POSummit, so that there is just one branch to take care of;
  
  With less underlying moving part, implementing a web interface would be easier.

We can make <lang>/messages/<repository>/<po_file>.po as <lang>/messages/<repository>/<module>_<po_file>.po.

That would make things more difficult. In fact modules must disappear from there, because otherwise repositories moving among modules will increase the number of moves. We just manage to remove the module name from json and desktop files translations, and having them back won't simply happen.

The idea to have show which module a program belong to from l10n.kde.org (which is a reason why probably need Damned Lies anyway, regardless of whether an online tool is there or not).

In T11070#198376, @ppeter wrote:

In T11070#198358, @ltoscano wrote:

I mentioned it elsewhere, but before doing this, it should be clear how much the changes made to the underlying repository (file rename, file changes which do not pass through the online tool) impact the online tool.
Also, I'd personally invest more time into preparation work which would reduce the amount of changes that may break the strings, like for example:

• flattening the directory structure removing the modules (so <lang>/messages/<repository>/<po_file> instead of <lang>/messages/<module>/<po_file>
• a mechanism to detect file renames and magically handles them
• move everyone to POSummit, so that there is just one branch to take care of;
  
  With less underlying moving part, implementing a web interface would be easier.

We can make <lang>/messages/<repository>/<po_file>.po as <lang>/messages/<repository>/<module>_<po_file>.po.

In T11070#198355, @sanecito wrote:

If KDE can't provide a test Weblate server, I can front one on my own dime. A server on Linode that meets the 2 core + 2 GB recommended specs goes for $20/month.

The other thing we'd need to know is who we could contact to connect the test Weblate instance to whatever integration/pre-prod infrastrucutre KDE has to make sure the seamless SVN integration bits all check out. In particular I believe some KDE sysadmin would need to provide some faceless account that would handle the automated pushes/pulls between integration/pre-prod Summit and Weblate.

In T11070#198358, @ltoscano wrote:

I mentioned it elsewhere, but before doing this, it should be clear how much the changes made to the underlying repository (file rename, file changes which do not pass through the online tool) impact the online tool.
Also, I'd personally invest more time into preparation work which would reduce the amount of changes that may break the strings, like for example:

• flattening the directory structure removing the modules (so <lang>/messages/<repository>/<po_file> instead of <lang>/messages/<module>/<po_file>
• a mechanism to detect file renames and magically handles them
• move everyone to POSummit, so that there is just one branch to take care of;
  
  With less underlying moving part, implementing a web interface would be easier.

So I made a RFC for this changes, and I hope it is helpful for migrating to Weblate. Hope it successful! :)

flattening directory structure will be a very good idea. since here a lot of file moving from one folder to another. Weblate doesn't support folder structure. But we can also use a script to map current folder structure to a flatten structure.

I mentioned it elsewhere, but before doing this, it should be clear how much the changes made to the underlying repository (file rename, file changes which do not pass through the online tool) impact the online tool.
Also, I'd personally invest more time into preparation work which would reduce the amount of changes that may break the strings, like for example:

• flattening the directory structure removing the modules (so <lang>/messages/<repository>/<po_file> instead of <lang>/messages/<module>/<po_file>
• a mechanism to detect file renames and magically handles them
• move everyone to POSummit, so that there is just one branch to take care of;

In T11070#198355, @sanecito wrote:

If KDE can't provide a test Weblate server, I can front one on my own dime. A server on Linode that meets the 2 core + 2 GB recommended specs goes for $20/month.

The other thing we'd need to know is who we could contact to connect the test Weblate instance to whatever integration/pre-prod infrastrucutre KDE has to make sure the seamless SVN integration bits all check out. In particular I believe some KDE sysadmin would need to provide some faceless account that would handle the automated pushes/pulls between integration/pre-prod Summit and Weblate.

If KDE can't provide a test Weblate server, I can front one on my own dime. A server on Linode that meets the 2 core + 2 GB recommended specs goes for $20/month.

My email to you bounced, @fbampaloukas. Could you email me at lydia@kde.org please?

Can we get a server to start testing with Weblate? It only takes one or two weeks to set up a test instance of Weblate + scripts for synchronization.

Unfortunately this goal wasn't selected as part of this round. If there is a critical mass of people who still want to push it forward please do! If support like financing a sprint is needed please reach out to the board.

Unfortunately this goal wasn't selected as part of this round. If there is a critical mass of people who still want to push it forward please do! If support like financing a sprint is needed please reach out to the board. We'd be happy to support this.

Unfortunately this goal wasn't selected as part of this round. If there is a critical mass of people who still want to push it forward please do! If support like financing a sprint is needed please reach out to the board.
Hopefully the selected Wayland goal will help make progress on this topic as well.

Unfortunately this goal wasn't selected as part of this round. If there is a critical mass of people who still want to push it forward please do! If support like financing a sprint is needed please reach out to the board.

Unfortunately this goal wasn't selected as part of this round. If there is a critical mass of people who still want to push it forward please do! If support like financing a sprint is needed please reach out to the board.
The selected Wayland goal will hopefully also be a good next step towards achieving this goal.

Unfortunately this goal wasn't selected as part of this round. If there is a critical mass of people who still want to push it forward please do! If support like financing a sprint is needed please reach out to the board.

Unfortunately this goal wasn't selected as part of this round. If there is a critical mass of people who still want to push it forward please do! If support like financing a sprint is needed please reach out to the board.

Unfortunately this goal wasn't selected as part of this round. If there is a critical mass of people who still want to push it forward please do! If support like financing a sprint is needed please reach out to the board.

Congratulations! This goal was selected as one of the three that we will concentrate on now.

Congratulations! This goal was selected as one of the three that we will concentrate on now.

Congratulations! This goal was selected as one of the three that we will concentrate on now. I sent you an email to coordinate the next steps.

I hope this will include adding wacom and graphic tablet support under wayland in the missing functionality list.

Regarding hamburger menus, I think Falkon/new Dolphin style is the best implementation because it gives the user the option to use the traditional menu or the hamburger menu. This is better for accessibility because people who rely on accelerators can enable a traditional menu and it ensures that the menu options will appear in the global or titlebar menu.

I think many contributors have asked when can we get an online translation system. But the answer is always: no, we won't do it for now.

In T11093#197099, @fsitter wrote:

You think sending your minions to insult me and then disabling my account will solve the issue? what will you do next? Disable registration so no one points out your hypocrisy? Which overlord made the decision to disable my account and for what?

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]

[spam comment removed by sysadmin]