Sure, i agree producing similar formatting to those of other tools is good.

It may be valid, but the "standard version" produced for example by msgfmt is the one where the spaces are at the end of the line, not at the beginning.
It is worth noting that KBabel first and Lokalize later, up to a certain version which I don't remember, did produce the "properly" formatted version.

When you say "incorrectly" you mean "not like i like it" or "not like gettext creates", right?

Git LFS is certainly an option for larger files as Gitlab provides us with support for that.

updated diff

In D10009#611209, @aacid wrote:

Can you share a .po file where this makes a difference?

And also can you provide a better description of what it does as a commit message? Because "Improvements for Gettext entries wordwrapping" is as generic as it gets.

updated diff

Can you share a .po file where this makes a difference?

We could try to remove all the images from the git history and add then again optimized in one commit at the end. It will be less radical than removing the complete history. Another solution would be to play with Git lfs (https://git-lfs.github.com) and have the images/videos/pdfs stored in another server.

Given the folder on disk is 1.3GB, and in the past people were known to perform image size optimisation passes of Subversion, it ending up at 3GB in size isn't a huge surprise.
I'm not sure what options we have for eliminating those image size optimisations from the history.

The current problem, I'm facing is that the repository is still 3Gb big :( and all my attempts to reduce it only improve the size from a few megabytes.

Process wise, what is the status of this migration?

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