Dear Translators, The target for the release v1.2 is Oct. 29th. The POT files have been updated if I read correctly. Since there are new materials or revamped ones, help is needed. :-) Well Guixer, if you would like to contribute and do not know how, translation is a really good mean. Fix typos, bad wording, new translations, etc. Do not hesitate to raise your hand if you need help to start. Currently, an .po entry looks like… --8<---------------cut here---------------start------------->8--- #. type: Plain text #: doc/contributing.texi:58 msgid "The easiest way to set up a development environment for Guix is, of course, by using Guix! The following command starts a new shell where all the dependencies and appropriate environment variables are set up to hack on Guix:" msgstr "La manière la plus simple de configurer un environnement de développement pour Guix est, bien sûr, d'utiliser Guix ! La commande suivante démarre un nouveau shell où toutes les dépendances et les variables d'environnements appropriées sont configurés pour travailler sur Guix :" --8<---------------cut here---------------end--------------->8--- …here translated, but sometimes untranslated ones ’msgstr ""’. Tooling helps to manipulate such files. For example: guix environment --ad-hoc emacs gettext \ -- emacs path/to/file.po And I am sure non-Emacs users have good other tools. Happy translation :-) simon
[-- Attachment #1: Type: text/plain, Size: 1855 bytes --] If you're not an emacs user, poedit is a very good tool. I personally use offlate, my own tool, for the translations. It's especially useful for interacting with the translation platform (here the TP but I support others). Both tools are available in guix. Le 9 octobre 2020 05:23:45 GMT-04:00, zimoun <zimon.toutoune@gmail.com> a écrit : >Dear Translators, > >The target for the release v1.2 is Oct. 29th. > >The POT files have been updated if I read correctly. Since there are >new materials or revamped ones, help is needed. :-) > >Well Guixer, if you would like to contribute and do not know how, >translation is a really good mean. Fix typos, bad wording, new >translations, etc. Do not hesitate to raise your hand if you need >help to start. > > >Currently, an .po entry looks like… > >--8<---------------cut here---------------start------------->8--- >#. type: Plain text >#: doc/contributing.texi:58 >msgid "The easiest way to set up a development environment for Guix is, >of course, by using Guix! The following command starts a new shell >where all the dependencies and appropriate environment variables are >set up to hack on Guix:" >msgstr "La manière la plus simple de configurer un environnement de >développement pour Guix est, bien sûr, d'utiliser Guix ! La commande >suivante démarre un nouveau shell où toutes les dépendances et les >variables d'environnements appropriées sont configurés pour travailler >sur Guix :" >--8<---------------cut here---------------end--------------->8--- > >…here translated, but sometimes untranslated ones ’msgstr ""’. Tooling >helps to manipulate such files. For example: > > guix environment --ad-hoc emacs gettext \ > -- emacs path/to/file.po > >And I am sure non-Emacs users have good other tools. > > >Happy translation :-) >simon [-- Attachment #2: Type: text/html, Size: 2142 bytes --]
Hi everybody, I've noticed that at least the pot file for the manual has to be updated again, as some fragments of guix.texi has been modified since the the pre-release was generated (e.g. section 2.4.2 Using the Offload Facility), therefore they cannot be translated. I've open http://issues.guix.gnu.org/issue/43934 with some minor details I've found during translation, but I'd recommend to perform a complete string freeze at some point before of the release to avoid these issues. WDYT? Happy hacking! Miguel
Hi,
Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis:
> I've open http://issues.guix.gnu.org/issue/43934 with some minor details
> I've found during translation, but I'd recommend to perform a complete
> string freeze at some point before of the release to avoid these issues.
I agree that a string freeze would be nice… but it’s difficult. There
are still a few patches out there (such as new package transformation
options) that will likely be merged soon. That said, this is non-core
functionality, so maybe we can live with that.
Anyway, if we’re aiming for Oct. 29th, perhaps we can do a last round a
week before?
Thanks!
Ludo’.
On Mon, 12 Oct 2020 at 14:30, Ludovic Courtès <ludo@gnu.org> wrote:
> Miguel Ángel Arruga Vivas <rosen644835@gmail.com> skribis:
>
> > I've open http://issues.guix.gnu.org/issue/43934 with some minor details
> > I've found during translation, but I'd recommend to perform a complete
> > string freeze at some point before of the release to avoid these issues.
>
> I agree that a string freeze would be nice… but it’s difficult. There
> are still a few patches out there (such as new package transformation
> options) that will likely be merged soon. That said, this is non-core
> functionality, so maybe we can live with that.
>
> Anyway, if we’re aiming for Oct. 29th, perhaps we can do a last round a
> week before?
From my point of view, a string freeze starting on Mon. Oct. 26th
seems the easiest to synchronize all etc.
And unfreeze once the branch is create &co.
Cheers,
simon
Hi simon and Ludo, zimoun <zimon.toutoune@gmail.com> writes: > On Mon, 12 Oct 2020 at 14:30, Ludovic Courtès <ludo@gnu.org> wrote: >> I agree that a string freeze would be nice… but it’s difficult. There >> are still a few patches out there (such as new package transformation >> options) that will likely be merged soon. That said, this is non-core >> functionality, so maybe we can live with that. Yup, I understand, and of course I don't want to slow the pace of the project at all. I guess that everybody understands (even expects) to wait a bit for certain translation from time to time, specially when the alternative means waiting for fancy new features. :-) >> Anyway, if we’re aiming for Oct. 29th, perhaps we can do a last round a >> week before? > > From my point of view, a string freeze starting on Mon. Oct. 26th > seems the easiest to synchronize all etc. > And unfreeze once the branch is create &co. Three days is a tight schedule, but could be enough if the number of changes keeps close to the current one (there are already 98 fragments without translation on guix-manual, none on guix and I didn't check guix-packages). Nonetheless, probably after the branch generation, I'd like to remove the paragraph that says "some fragments may be found in English" from the release version of the Spanish manual (but keep it with the info downloaded by guix pull), checking that it's true, obv. Best regards, Miguel
Dear,
On Mon, 12 Oct 2020 at 18:16, Miguel Ángel Arruga Vivas
<rosen644835@gmail.com> wrote:
> > From my point of view, a string freeze starting on Mon. Oct. 26th
> > seems the easiest to synchronize all etc.
> > And unfreeze once the branch is create &co.
>
> Three days is a tight schedule, but could be enough if the number of
> changes keeps close to the current one (there are already 98 fragments
> without translation on guix-manual, none on guix and I didn't check
> guix-packages).
Maybe I am missing something. Now the translation 1.2.0-pre1 is open,
so it is almost 3 weeks (even if I know it is maybe not enough, well
we have to fix some deadlines somehow :-)).
The last week, we could string freeze for polishing and not run after
an always moving target.
From my point view, a longer freeze would not help to have the work
done. I do not know. What do you think it could be better?
All the best,
simon
Hi, First of all, thanks. And second, to leave a clear statement about the main point: I agree with your proposed time frame for the string freeze, October 26th (freeze) to 29th (release). zimoun <zimon.toutoune@gmail.com> writes: > Maybe I am missing something. Probably this context helps: I've already uploaded to TP the translation for the manual, so I can compare the "old" pot (the one uploaded to TP) with the "new" one (the one I generated today on my machine). > Now the translation 1.2.0-pre1 is open, so it is almost 3 weeks (even > if I know it is maybe not enough, well we have to fix some deadlines > somehow :-)). Nobody likes deadlines---at least not me, hehe---but I believe they can be really useful sometimes. :-) > The last week, we could string freeze for polishing and not run after > an always moving target. Yup, that's the main advantage of freezing: you can focus as much as possible on the little and not so little details, like bug hunting. > From my point view, a longer freeze would not help to have the work > done. I do not know. What do you think it could be better? I agree that a longer string freeze wouldn't a big difference, and even may hurt. At least the manual is a huge work that probably cannot be done in weeks from scratch, so I'm not thinking about the string freeze as "the time frame to perform the translation" but "a time frame to check the translation already done and fix last minute issues/features". Besides, sorry if the word 'tight' sounded as a complaint meaning protest, if so it'd really be a complaint meaning grief for my schedule, as I'm unable to dedicate much time on working days. Happy hacking and translation too! Miguel
Dear, On Mon, 12 Oct 2020 at 23:26, Miguel Ángel Arruga Vivas <rosen644835@gmail.com> wrote: > First of all, thanks. And second, to leave a clear statement about the > main point: I agree with your proposed time frame for the string freeze, > October 26th (freeze) to 29th (release). Hope that you noticed the slip. The target is Nov. 6th. See [1] for details. Thanks, simon 1: https://lists.gnu.org/archive/html/guix-devel/2020-10/msg00300.html