The KDE project which touches Localization [l10n] (and Internationalization [i18n])
Tue, Feb 18
Sure, i agree producing similar formatting to those of other tools is good.
Sun, Feb 16
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.
Sat, Feb 15
Thu, Feb 13
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.
Wed, Feb 12
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?
Jan 18 2020
Jan 11 2020
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.
Jan 9 2020
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.
Jan 4 2020
Is there any reason we can't proceed with putting in place the redirect?
Jan 3 2020
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 :)
Dec 29 2019
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
Dec 28 2019
The migrated repo does not include scripts from */x-test/internal/, is that OK?
Dec 20 2019
Dec 19 2019
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.
Dec 18 2019
Dec 14 2019
Dec 13 2019
Looks like it resulted in a new empty dir templates/messages/kdesdk/. Not a big problem though.
Dec 12 2019
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
Dec 11 2019
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?
Dec 10 2019
+1, that's fine with me too.
I agree, I hate this kind of ambiguous language.