Kross support removed from Lokalize in https://commits.kde.org/lokalize/a0dc91ddc032485f850bc8fd5333e5a8a58024b6.
- Queries
- All Stories
- Search
- Advanced Search
Advanced Search
Mar 1 2024
Jun 22 2023
Jun 5 2022
This seems obsolete.
Feb 18 2022
Jan 3 2022
Aug 31 2021
Yes, I believe the approach with running-and-forgetting the interpreter binary should work for "opensrc" to some extent. One trouble I see though is, it's harder to enforce system requirements to have some GUI in Python to provide feedback for the user, for example if something goes wrong.
Aug 30 2021
One Lokalize script that I personally used for a while was https://invent.kde.org/sysadmin/l10n-scripty/-/blob/master/lokalize/opensrc.py. I actually ported Kross to KF5 because I wanted that specific script to work again. OTOH I hadn't been translating (and therefore using Lokalize) much lately.
Aug 25 2021
Two big questions:
- What is the chance this gets implemented & released in KF5, before KF6 is ready?
- Would the languages/locales' dataset be sufficient to replace the list of KDE languages currently hardcoded in KF5::KConfigWidgets? See thread for more background, please consider the case of en_GB.
Mar 27 2021
Jan 14 2021
Btw I've started slowly rewriting scripty in Go because
- I like Go more than bash.
- It's easier to make it more configurable than in the current state with a set of scripts calling each other. We need configurability to share codebase across branches and to let users run parts of scripty end-to-end (will be useful for www that needs more frequent syncs).
- it's easier to parallelize things in Go, so we could shorten the running time.
In T13514#237699, @aacid wrote:"Git should facilitate integration with external translation file trees maintained by Linux distributions (e.g. BaseALT)"
Let me rephrase this for you: "We're doing things wrong, can you please change your upstream behaviour so it's less painful for us to do things wrong?"
Jan 2 2021
Migration to Git is over, abandoning this patch.
Roughly the same was done in https://invent.kde.org/sysadmin/l10n-scripty/-/commit/6bad01a4aea8cb4c43ba57a904c1c882ebc4fbe9 , abandoning this patch.
Nov 14 2020
ping?
Oct 12 2020
I'm assuming we're waiting for Luigi to adapt makemessages and kick start the migration process. @ltoscano, is there anything I can help with to get the Git migration done sooner?
Aug 20 2020
Shall we discuss how the system is going to handle multiple translation branches (e.g. trunk/l10n-kf5, branches/stable/l10n-kf5, ...) ?
Aug 19 2020
@nalvarez, could you please update on the status of this ticket? Are you blocked on something? Do you need help?
Aug 18 2020
In T13514#237629, @pino wrote:Git should facilitate integration with external translation file trees maintained by Linux distributions (e.g. BaseALT)
@aspotashev can you please explain why these distros care about the layout of our translations? When packaging upstream releases they ought to use translations as available in release tarballs, not pick random files from upstream translation trees.
Aug 17 2020
In T13514#237618, @ltoscano wrote:In T13514#237617, @aspotashev wrote:I'm not sure what you mean here, can you please elaborate? The tooling to simplify moving of translations between directories is part of step #4 of the roadmap. Something like super-duper-tool mv kscreenshot/kscreenshot.po spectacle/spectable.po would create a commit in each of the Git translations repositories and git push all of them, possibly retrying this operation in a case of a merge conflict.
I don't want to have a tool to push things in all repositories first without reducing the number of occurrences when this can happen. Also, summit should get that support first.
In T13514#237610, @ltoscano wrote:The points can be dune until the moving of translations is not automated. Otherwise having to do the operations on a set of per-languages git repositories will be impossible.
Jun 12 2020
Ping?
Jun 7 2020
Jun 1 2020
May 24 2020
Thanks!
May 23 2020
ping?
Apr 24 2020
FWIW, kde-ruleset.git is also missing COPYING files and license headers.
In D25929#656114, @nalvarez wrote:I think you should commit this as-is and we can do changes later directly in kde-ruleset.
Apr 10 2020
Apr 4 2020
Feel free to mark https://bugs.kde.org/show_bug.cgi?id=416940 fixed as soon as this patch is submitted. You can add a line "BUG: 416940" to the commit message to have the ticket closed automatically on git push.
Why CTR and not GCM (https://en.wikipedia.org/wiki/Galois/Counter_Mode)?
To clarify: I identified that we can't just migrate to Git and remove the scripty source code from SVN without changing makemessages. Migration can be done as follows:
Mar 28 2020
I think I need to explicitly specify license for these new files. Not sure which license to choose, by default I would pick MIT because it's one of the most permissive ones.
Mar 27 2020
In D26076#627394, @aacid wrote:Just to be sure, this needs https://phabricator.kde.org/D25929 (or rather the repo resulting from it), right?
As I mentioned in https://phabricator.kde.org/T4803#213612 , I ran svn2git with these rules in December to produce https://github.com/aspotashev/converted-scripty-v2 for evaluation.
Mar 8 2020
ping?
Mar 7 2020
Mar 3 2020
Клик стоил около 20 рублей?
Feb 9 2020
Jan 5 2020
Jan 3 2020
ping?
Dec 28 2019
The migrated repo does not include scripts from */x-test/internal/, is that OK?
Dec 24 2019
Dec 23 2019
In D26168#581665, @kossebau wrote:Seems you went fully "at it", good work :)
"after string freeze" meant "after relase tagging for string freeze reasons" , right? ;)
will try to push around January 5, 2020 after string freeze
will try to push around January 5, 2020 after string freeze
In D26168#581637, @kossebau wrote:Looks good to me for what I know as programmer, but none-translator :)
While at it, for consistency the other tab titles could also get a "@title:tab" UI marker context?