The current HIG suggest a progress bar for these scenarios (https://hig.kde.org/components/assistance/progress.html), but I’m not sure where that would go in Lokalize, and it would definitely require more complex changes.

Maybe KMessageWidget within the main UI component (the view of the source and target strings) would make sense…

Notice that, while the code is in a view, the action is triggered from an application-wide menu.

In D25771#572906, @broulik wrote:

I don't know what the UI looks like or what workflow it serves but judging from the fact it's a QDockWidget I assume a KMessageWidget inside the dock would be more fitting than a free-floating notification?

The tooling improved a bit for https://kde.org/announcements/releases. The next step would be to create a python package with the script so that we don't need to duplicate the code for each repo.

Is there any reason we can't proceed with putting in place the redirect?

Oh, the "accept revision" is just like the feature "Approve" in GitHub and it is my expection. So I think I didn't do anything wrong :)

ah you mean that they are not part of "scripty" itself but of x-test, sure i guess that's fine (at least for now)

We need those two scripts

The migrated repo does not include scripts from */x-test/internal/, is that OK?

oh ok, I will start with some other issue then.

I already submitted a patch: https://phabricator.kde.org/D25878

Do we need to make changes in code to remove this ambiguity? I want to start working with KDE softwares.

Looks like it resulted in a new empty dir templates/messages/kdesdk/. Not a big problem though.

Please see the results of my second attempt to use svn2git: https://github.com/aspotashev/converted-scripty-v2 (can't push to KDE Git hosting because hooks decline it)
I used these scripts: https://phabricator.kde.org/D25929

ok, fair enough, let's go for it, but if you break something you fix it yesterday ;)

yes, that's what our other repos have, for example Okular says

Another question to everyone: do you think we should add an SVN commit reference to all commit messages in Git?

+1, that's fine with me too.

I agree, I hate this kind of ambiguous language.

Relavant code is KFormat::formatRelativeDate

In T12058#208879, @aspotashev wrote:

I would like to add one more idea: https://kde.org/images/screenshots/ can be removed in favor of https://cdn.kde.org/screenshots/ that mirrors https://cgit.kde.org/websites/product-screenshots.git/

However some screenshots are not available in product-screenshots.git yet (e.g. simon.png), may need importing.

In T4803#213133, @pino wrote:

• I tried to incorporate the scripts from kde-common/, at least makemessages, under prefix kde-common/ in branch master. However this led to also pulling unnecessary kde-common/admin/, kde-common/accounts and others.

Leave kde-common away, as it does not belong to this. If needed, that will be converted separately (it has a different history).

Nice start.

Please see the results of my first attempt to use svn2git: https://cgit.kde.org/scratch/aspotashev/converted-scripty-v1.git/

I don't know what the UI looks like or what workflow it serves but judging from the fact it's a QDockWidget I assume a KMessageWidget inside the dock would be more fitting than a free-floating notification?

Hello, it's me again.

In D25348#568616, @aacid wrote:

i can see this is a potential bugfix, but honestly, i'd just leave the kde4 branches die (unless this is blocking you heavily in some way)

@nalvarez ping?

May be the original author is not following Phabricator. You can try and ping him in the bugs.kde.org report or by email.

We never got a proper explanation of what this does or how it works.

It has been more than a year. Should we close this and https://bugs.kde.org/show_bug.cgi?id=380007?

i can see this is a potential bugfix, but honestly, i'd just leave the kde4 branches die (unless this is blocking you heavily in some way)

In T4803#208644, @ltoscano wrote:

Now, please, let's keep this ticket as it is: we need to import the full history *with branches* anyway.

I would like to add one more idea: https://kde.org/images/screenshots/ can be removed in favor of https://cdn.kde.org/screenshots/ that mirrors https://cgit.kde.org/websites/product-screenshots.git/

Well, this is a bug fix. Without this patch preparetips and svn-clean won't run unless you cloned the two mentioned repos manually.

In T12058#208627, @ognarb wrote:

@aacid Completely agree, it's the reason why I added a lot of information to https://community.kde.org/KDE.org/Local_Setup.

In terms of /applications, that needs to remain separate because the generator relies on being able to add it's files to the contents of websites/kde-org-applications prior to it being uploaded.

Anyway, the real world process is not even the one you are describing. The point is here is not to fix this set of script: it's to throw it away in the long run and have it something more flexible. Hence a minimal amount of work should go into keeping this scripts alive. Each branch can live on its own own until it's unified.

In T4803#208570, @aspotashev wrote:

In T4803#208483, @ltoscano wrote:

As I write initially:

• separate branches, as it's easier to adapt the current code;

It's almost adapted already.

• Support work in a different path: D25333 + needs a few more changes regarding subdirs file
• Change of paths in trunk/kde-common/makemessages - easy
• Add git clone/pull for scripty.git in trunk/kde-common/makemessages - easy
  
  May be I don't see some more pitfalls?

What is the gain? This branch can stay as it.

@aacid Completely agree, it's the reason why I added a lot of information to https://community.kde.org/KDE.org/Local_Setup. Since there was only really outdated information until recently and I needed to figure the installation process alone. The documentation is not perfect but at least the main information are here.

I disagree with having magic setup unless there's clear instructions provided

With regards to kdeslides/ these should be shifted to share.kde.org, which means they do not require a Git repository.

In T4803#208465, @pino wrote:

In T4803#208462, @aspotashev wrote:

1. Import the 5 branches (*/l10n-kf5*/scripts and */l10n-kde4/scripts) to Git as subling directories:
   • branches_stable_l10n-kde4

Ugh no, please import them as branches, as they actually are.

As a counter-argument to this statement, I'm going to explain why */l10n-kf5*/ and */l10n-kde4/ are not real branches. Even though the various scripts/ directories are stored under branches/stable/ and trunk/ in SVN, they are not used as branches anymore.

In T4803#208483, @ltoscano wrote:

As I write initially:

• separate branches, as it's easier to adapt the current code;

You did not convince me, sorry.

And of course the kde4 branches won't need.any update: one is already gone, the other will be soon.

As I write initially:

• separate branches, as it's easier to adapt the current code;
• later we will transition all kf5 branches to use master, in a non disruptive way.

In T4803#208462, @aspotashev wrote:

1. Import the 5 branches (*/l10n-kf5*/scripts and */l10n-kde4/scripts) to Git as subling directories:
   • branches_stable_l10n-kde4
   • branches_stable_l10n-kf5
   • branches_stable_l10n-kf5-plasma-lts
   • trunk_l10n-kde4
   • trunk_l10n-kf5

In T4803#154804, @ltoscano wrote:

• trunk/l10n-kde3
• branches/stable/l10n

There is no reason for using multiple branches in scripty.git, it will only make usage and development harder:

My top-level plan is to

ok, i guess

Go for ti

:) nice!

🎉 it works: