Tails

#2 Updated by intrigeri 2019-08-31 15:04:45

I wrote “the earlier, the better”, but let’s not do this before 3.16 and 4.0~beta2 are out: if anything goes wrong, we don’t want to disrupt the release process.

#4 Updated by intrigeri 2019-09-12 12:55:19

If we don’t manage to get this done in time for 4.0, we can downgrade po4a to the Stretch version in 4.0 and postpone.

#11 Updated by emmapeel 2020-01-14 10:06:51

At the moment the instructions on the website ( https://tails.boum.org/contribute/build/website/ ) tell you to install po4a/stretch but when trying to do it from Tails 4.2.x, the server says something like: could not find po4a in stretch distribution.

Installing po4a works well, though.

#12 Updated by intrigeri 2020-01-15 10:32:18

Hi @emmapeel,

> At the moment the instructions on the website
> ( https://tails.boum.org/contribute/build/website/ ) tell you to
> install po4a/stretch but when trying to do it from Tails 4.2.x, the
> server says something like: could not find po4a in
> stretch distribution.

AFAICT, the instructions in the “Build the website in Tails” section don’t have this problem.
So I’ve updated that doc page a bit:

• increase the chances Tails users follow the relevant instructions
• improve a bit the non-Tails instructions (not relevant here, but it was cheap while I was at it)

Better?

#16 Updated by CyrilBrulebois 2020-03-01 16:49:33

Hey, I was just wading through some tickets targetting 4.4, and I was wondering whether this might be merged in time for it, so that I can prepare my host environment accordingly?

#17 Updated by intrigeri 2020-03-01 17:08:26

> Hey, I was just wading through some tickets targetting 4.4, and I was wondering whether this might be merged in time for it, so that I can prepare my host environment accordingly?

Thank you for caring. The plan is to merge this early in a release cycle, so that translators have as much time as we can give them to unfuzzy tons of strings.
So no, it won’t get merged in 4.4. Best case, during this dev cycle, I’ll prepare branches that can be merged soon after 4.4 is released.

#23 Updated by hans 2020-03-24 15:56:08

FYI we are currently in the process of porting f-droid.org to build entirely using Debian/buster packages, including po4a. There were some Markdown bugs fixed recently, post 0.55, that are very much worth having. I recommend using at least 0.58 from git. We have one last bug open, after that I’m going to push for a 0.58 release which can then go to buster-backports. This is the bug in question: https://github.com/mquinson/po4a/issues/196

These are the bugs that were fixed:

• https://github.com/mquinson/po4a/issues/172
• https://github.com/mquinson/po4a/issues/194
• https://github.com/mquinson/po4a/issues/195

#24 Updated by intrigeri 2020-03-25 10:23:09

Hi @hans,

> There were some Markdown bugs fixed recently, post 0.55, that are very much worth having. I recommend using at least 0.58 from git. We have one last bug open, after that I’m going to push for a 0.58 release which can then go to buster-backports. This is the bug in question: https://github.com/mquinson/po4a/issues/196
>
> These are the bugs that were fixed: […]

Great, thanks for the pointers!
I’m glad we’re on the same boat here, even if we recently were not able to jump on other boats that would have been nice to share :)

These bug fixes indeed look potentially useful. On the Tails side, the improvements we care about most are in 0.55 so I think I’ll first go through this upgrade (which is basically ready to go), and cross the 0.58+ bridge in another iteration, once 0.58 is in buster-backports and all relevant Tails persons run Buster or newer.

#25 Updated by hans 2020-03-25 11:23:01

From what I’ve seen, adding the step to 0.55 in between will create new issues that you will have to migrate from, while jumping straight to 0.58 looks like the same amount of work as 0.55.

#26 Updated by intrigeri 2020-03-26 08:12:49

Hi @hans,

> From what I’ve seen, adding the step to 0.55 in between will create new issues that you will have to migrate from,

Thank you. This makes me very curious!
Are you referring to regressions in 0.55 compared to what we’re currently using (0.47)?
Or anything else?

#27 Updated by hans 2020-03-26 08:48:26

I wouldn’t call them regressions, but https://github.com/mquinson/po4a/issues/194 is a good example. Basically, using 0.55 will give your translators lots of

```bash

and

```

strings to translate, while 0.58 will not. Going from 0.55 to 0.58 would then remove all those as strings.

#28 Updated by intrigeri 2020-03-27 09:12:59

Hi @hans,

hans wrote:
> I wouldn’t call them regressions, but https://github.com/mquinson/po4a/issues/194 is a good example. Basically, using 0.55 will give your translators lots of

```bash

and

```

strings to translate, while 0.58 will not.

Thank you. Luckily (for the matter at hand), we don’t use code fences.

I’ll come back to it in a few weeks and we’ll see what’s the 0.58 status and whether we still need to support Stretch at that time.

#29 Updated by hans 2020-04-01 20:27:31

FYI, there has been a bunch of other work on smoothing out the process of using the `po4a` command to do all the syncing. That new work means f-droid.org no longer needs a custom script to run `po4a`. The maintainer is soliciting feedback on improving the po4a.conf format, in case you are interested: https://lists.po4a.org/archives/list/devel@lists.po4a.org/thread/NUVSGUGKTYDTA66RSMHGE6ZZH3Q2CMNY/

#30 Updated by intrigeri 2020-04-02 07:44:56

> FYI, there has been a bunch of other work on smoothing out the process of using the `po4a` command to do all the syncing. That new work means f-droid.org no longer needs a custom script to run `po4a`. The maintainer is soliciting feedback on improving the po4a.conf format, […]

Thanks. Actually, we don’t use the po4a(1p) program. We use the ikiwiki po plugin, which itself uses the Locale::Po4a::* Perl libraries.

#34 Updated by intrigeri 2020-04-14 14:36:16

Hi @anonym,

> As for the changes in the PO files, oops, lots of new fuzzy lines with trivial fixes (almost 1500 occurrences AFAICT) so it sure does look like this will add lots of busy work for our translators. :/

Right.

The end-goal here is to make translators’ life better on the long term: the new po4a extracts strings in a way that’s easier to translate, and harder to make mistakes about (e.g. the infamous inconsistent newline at end of string error we get spammed with regularly).

Initially, the plan here was to fix the problem you’re mentioning, to avoid making translators’ life worse on the short term.
But when fixing this problem was part of this issue, for months nobody on the FT volunteered to tackle it.
So in the end I gave up and decided that the long-term savings (for translators) were worth the short-term annoyance (for translators too), and that the perfect was the enemy of the good. It’s a trade-off.

> I wonder, are these ones “trivial” enough to fix automatically with some sed-fu or similar?

I considered this. I believe the difficult part is not to remove the now-extraneous \n. It’s to decide whether after doing so, it’s OK to drop the fuzzy marker: to do so, one has to check if the string became fuzzy solely because of the po4a upgrade. So one needs to essentially interface with Git-diffs-of-PO-files. That does not sound trivial to me.

#35 Updated by anonym 2020-04-14 18:38:41

intrigeri wrote:
> So in the end I gave up and decided that the long-term savings (for translators) were worth the short-term annoyance (for translators too), and that the perfect was the enemy of the good. It’s a trade-off.

Makes perfect sense! Still, do you think it would be worth me spending an hour on it tomorrow to look for a non-perfect solution that cheaply/safely kills a large amount of them?

BTW, why is po4a (0.47-2) in in our (base branches’) APT suites? In Bug #17572 I noticed this, and speculated it was because we wanted to make this desired version easily available for our translators that do their work inside Tails, otherwise they would have to add stretch APT sources themselves. Any clue?

Any way, it seems to me that we definitely should remove po4a 0.47-2 from our (base branches’) APT suites as part of moving to po4a 0.55-1 (i.e. resolving this ticket), right?

#40 Updated by intrigeri 2020-04-15 08:17:24

Hi @anonym,

> Makes perfect sense! Still, do you think it would be worth me spending an hour on it tomorrow to look for a non-perfect solution that cheaply/safely kills a large amount of them?

I think so, yes, as long as we don’t unduly remove fuzzy markers that were there before the post-po4a-upgrade PO files refresh.
I’ll happily review such a branch.
Please base this work on our current master branch (that had the po4a upgrade merged in already).

> BTW, why is po4a (0.47-2) in in our (base branches’) APT suites? In Bug #17572 I noticed this, and speculated it was because we wanted to make this desired version easily available for our translators that do their work inside Tails, otherwise they would have to add stretch APT sources themselves. Any clue?

It was mostly for technical writers (AFAIK, no regular+active translator works in Git anymore).

> Any way, it seems to me that we definitely should remove po4a 0.47-2 from our (base branches’) APT suites as part of moving to po4a 0.55-1 (i.e. resolving this ticket), right?

This would be good. Can you please handle this on Bug #17572?

FWIW, I don’t understand the “definitely” part: it sounds like there will be problems if we don’t remove it. I don’t know what these problems are, besides having unused cruft in our APT suites, which AFAICT, is closer to the normal/usual situation than to an exceptional situation that definitely needs solving.

#43 Updated by anonym 2020-04-15 08:47:42

intrigeri wrote:
> Hi @anonym,
>
> > Makes perfect sense! Still, do you think it would be worth me spending an hour on it tomorrow to look for a non-perfect solution that cheaply/safely kills a large amount of them?
>
> I think so, yes, as long as we don’t unduly remove fuzzy markers that were there before the post-po4a-upgrade PO files refresh.
> I’ll happily review such a branch.
> Please base this work on our current master branch (that had the po4a upgrade merged in already).

Ok, will do a very careful attempt! Stay tuned!

> > Any way, it seems to me that we definitely should remove po4a 0.47-2 from our (base branches’) APT suites as part of moving to po4a 0.55-1 (i.e. resolving this ticket), right?
>
> This would be good. Can you please handle this on Bug #17572?

“Definitely!” >:)

> FWIW, I don’t understand the “definitely” part: it sounds like there will be problems if we don’t remove it. I don’t know what these problems are, besides having unused cruft in our APT suites, which AFAICT, is closer to the normal/usual situation than to an exceptional situation that definitely needs solving.

Indeed, not sure why I felt the need to make such a strong claim. I had no adverse consequences in mind, just “let’s properly clean up”.

#44 Updated by intrigeri 2020-04-15 10:12:46

> Indeed, not sure why I felt the need to make such a strong claim. I had no adverse consequences in mind, just “let’s properly clean up”.

Thank you, @anonym, for the clarification. We’re on the same page :)

#46 Updated by intrigeri 2020-04-15 14:09:25

> I managed to unfuzzy 1386 strings! Please have a look at the branch: doc/17005-unfuzzy

Merged, thanks!