From: Julien Lepiller <julien@lepiller.eu>
To: guix-devel@gnu.org
Subject: Re: Improving the translation process
Date: Thu, 06 Feb 2020 14:20:53 -0500 [thread overview]
Message-ID: <19B892FD-C27C-4E9F-BEF8-3EE4053DB711@lepiller.eu> (raw)
In-Reply-To: <5C0BF556-0087-41D9-AFF1-A48F3762CC04@lepiller.eu>
Le 6 février 2020 12:01:51 GMT-05:00, Julien Lepiller <julien@lepiller.eu> a écrit :
>Hi guix!
>
>Our current translation process involves sending a source tarball to
>the TP. Updating a translation is a manual process that can't be done
>too often, and I don't think the TP is very user friendly. I'd like to
>set up another service, such as weblate.
>
>The Fedora people have recently switched to it and are inviting other
>free software projects, so it could be a nice way to setup this new
>process, before we can make our own service and host it. I've talked
>with someone responsible for weblate at Fedora, and they would be
>pleased to help us. We could also apply for the main instance at
>hosted.weblate.org.
>
>As I see it, we don't want any of these instances to have push rights
>on our repos. The idea is to have a separately hosted repo for
>translations, used only by weblate. We would host a bot to regularly
>push up-to-date pot files to that intermediate repo, which will update
>weblate's data. Weblate would push to that repo and any guix commiter
>would be able to download, check and commit new po files. No commiter
>would need to have write access to that repo: only the bot and weblate
>would use it. It could be on savannah or fedora's inhrastructure or
Actually, not on fedora's infrastructure :) but hosting a repo on a server or on a separate namespace at savannah shouldn't be too complicated.
>somewhere else, but not in the guix namespace at savannah, because
>access rights are per-namespace iiuc.
>
>This new process would allow for daily or weekly updates of
>translations, which fits better with our rolling-release model and will
>help translators of the manual do work on a regular basis instead of
>per-release. The interface is way more understandable for newcomers who
>will quickly understand how to contribute. The downside is, as always,
>more fragmentation in the l10n community esp. if we go for our own
>instance.
>
>WDYT?
next prev parent reply other threads:[~2020-02-06 19:21 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-06 17:01 Improving the translation process Julien Lepiller
2020-02-06 19:20 ` Julien Lepiller [this message]
2020-02-06 21:41 ` pelzflorian (Florian Pelz)
2020-02-07 13:00 ` Julien Lepiller
2020-02-07 13:46 ` pelzflorian (Florian Pelz)
2020-02-07 21:50 ` Ludovic Courtès
2020-02-09 23:55 ` zimoun
2020-02-10 0:03 ` Julien Lepiller
2020-02-11 14:23 ` Ludovic Courtès
2020-02-11 16:08 ` Julien Lepiller
2020-02-24 16:23 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19B892FD-C27C-4E9F-BEF8-3EE4053DB711@lepiller.eu \
--to=julien@lepiller.eu \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.