Weblate, not just for SecureDrop

Translations
1

Bonjour,

Well, there are a few other projects using weblate in the privacy tools arena :wink: But most use transifex and it takes a motivated volunteer localizer to get used to weblate. Last week during the Tor conference in Rome, a few projects got together (Tor, Tails, EFF, SecureDrop, OnionShare, Guardian Project, F-Droid, riseup, and Onion Browser) and collectively decided it was a good idea to adopt weblate.

An open mailing list was created for communication and Hans-Christoph Steiner is working on a funding proposal that would allow to retain the services of @nijel to implement features. This is a great turn of events and it gives me hope about weblate adoption :slight_smile:

There will be a meeting at https://meet.jit.si/linguine Friday March, 23, 9am Paris/Berlin time to discuss all this. I will be there and advocate for:

If you have more ideas please speak-up and Iā€™ll relay them in case you cannot join!

Cheers

2 Likes
2

My notes from the meeting (@communia, Hans, @erinm, @kingu).

  • Guardian via Hans would get the funds, from OTF most likely
  • Hans explains that the funds would likely be spent on
    • People who help a given project to migrate to weblate
    • Development of features via @nijel
    • Allowing localizationlab to host a shared weblate instance
    • Conduct user research to prioritize the features that should be implemented
  • @erinm highlighted that there has been work done toward using pootle and there also is funding to go in this direction. Hans noted that no project in the group uses pootle.
  • @kingu has a list of features that weblate would need to implement and funds some of them
  • @erinm helping localizers move to weblate requires significant work on my part because they are not used to the interface and I need clear the confusion. It would help a lot if a large project such as tor moves to weblate because more localizers will know about the interface and the workflow.

Action items:

  • @erinm will collect feature requests from various projects

The meeting went for 70 minutes and it was an opportunity for me to understand more about the context. And also to express my personal opinion regarding a few things:

  • having paid staff to provide technical support for weblate would not be a good thing, what should be done instead is to start with an infrastructure that is supported by a community of volunteers and only after it starts to get adoption, think about injecting money and paid staff to supplement the effort. It is more sustainable because the infrastructure does not depend on funding. Funding helps, but it is not the root of all things.
  • having weblate support discourse for comments via the discourse API would allow to have a common discourse platform for a number of projects. localizers cannot be expected to go to each project communication channels: itā€™s too much diversity.
  • when enabling translation for their project, developers spend almost all their effort bridging weblate with their project. For SecureDrop this is months of developer work. It would be a great help if best practices, scripts and documentation was provided by localizationlab so a project willing to use weblate could just re-use that, if they so choose.

Iā€™ve missed a lot of things that we said, not very good at taking notes, please add if you remember more than I do!

2 Likes
3

Is the objective to have 1) a hosted Weblate (one weblate for ā€œallā€ projects) with many different projects using the same weblate instance, 2) or is it having a number of weblates - one for each project?

+1 to @erinm comment.

If the objective is 2) above (many weblates) it would be important to maintain consistency across the different weblates.

There will be localisers working across different projects and consistency in interface will help them.

@dachary as we discussed at the IFF LocLab this year, Iā€™d like to suggest a ā€œfeatureā€ where the particular string and user interaction to create it are provided to the weblate user with an animation.

This will provide the localiser with some better context on this particular message.

Good news and Iā€™m looking forward to seeing more.

4

@ei8fdb, from my understanding this is still undetermined, however I imagine a mixed model might make the most sense. Having a Localization Lab hosted Weblate for projects who donā€™t have the resources to manage their own instance, and then independent instances connected through shared resources and login. Just a thought on my end. There was also the suggestion by @kingu that all projects should simply join the existing Hosted Weblate instance.

Can you explain this a bit more? I am not clear what this refers to. Do you mean offering something like a mini demo in addition to string context?

5

What would make sense to me is both. For instance localizationlab hosting a shared weblate instance for projects who do not want to self host. And self-hosted weblate instances for projects like SecureDrop who think important to do so for some reason.

1 Like
6

The idea would be to have a localized screenshot that is an animated gif showing the interaction steps that lead to the web page that displays the translated string. As opposed to a static screenshot showing the translated string because it does not provide much context about why the user got there.

When a project implements functional tests and creates screenshots as part of these automated tests, collecting screenshots and bundling them into an animated gif is relatively simple.

1 Like
7

Youā€™re right a mixed model would be a better idea. If youā€™re a large enough/with specific needs project you could host your own, otherwise use Weblates hosted option.

Well, a micro-demo (?) of where that strong is used. So as an example:

  1. A user (who is creating an account) enters their chosen password
  2. The system then displays an error message string ā€œYouā€™ve entered 15 characters. These passwords must be 30ā€ (thatā€™s a bad error messageā€¦but)
  3. The user then enters the required 30 characters.
  4. The user then presses whatever button to continute.

The animation would be of steps 1-4. This would give the localiser more context of the type of user interaction that leads to that message being displayed.

This animation would be presented on the page for that string.

From the discussion with @dachary it seemed this was a possibility, at least in SecureDrops development process as they use automated testing to verify code.

These automated tests produce, automatically, a series of screenshots. They could be used to produce this animation.

8

Hah, I think we were typing at the same time. :rofl:

9

Just a small note to this: Pootle is currently not maintained and the guys behind Pootle do not expect to work on it in near future. They are now having different focus.

The documentation looks quite good and would mostly apply to other projects as well, any chance some of that would be contributed to the Weblate docs? There seems to be license incompatibility though (SecureDrop is AGPL while Weblate is GPL).

1 Like
10

Ah, this is unfortunate :frowning: Not that I would like to use pootle but because itā€™s good to have diversity. Do you have URL explaining this development?

11

I donā€™t think it was publicly stated anywhere, but it was one of the topic weā€™ve discussed this at FOSDEM this year. On the other side you can probably notice that also from shape of the GitHub project (no commits for four months, quite a lot of pull requests without reviewā€¦).

On the other side the transalte-toolkit (which both Pootle and Weblate use) is still receiving some attention and not only from me :-).

1 Like
12

I guess this makes sense considering their main dev. moved over to Mozilla. It is sad because they very much valued building robust language teams and advocating for language diversity and minority languages.

13

Not all projects will find a home with Hosted Weblate, though if you are on Transifex now, that argument becomes one of adjusting for minutia of what is is a greater question of an all-encompassing beneficial move.

Move the ones that want to move to Hosted Weblate now, it is a perfect fit for a lot of projects, whereas the two closed source projects of LocalizationLab could help the others, and it, by not tainting their presence on a shared hub.

TL;DRs

Hosted Weblate presents itself as the god-send of Libre software hosting that Pootle did not, and have not managed to set up yet. They too seemed too concerned with scaling into infinity to not to make the move out of safety, and find themselves equally behind the curve.

Concern for all possible angles becomes at some point procrastination, what is possibly a lost cause with Pootle, and wasnā€™t ready in Weblate then, is available with Weblate now.

The projects that have security concerns for not being on Hosted Weblate, have developers more than capable of setting up their own instance of either Pootle or Weblate.

In an ideal world, all aspects of community and security combine. This could be done by making even lone instances able to federate their pool of translated strings, dictionaries, and mutual visual updates over to Hosted. Logins are to a very large degree solved, since one can use the ones that most of these instantly moveable projects host their development on.

Localization Lab making its own instance strikes me as not opting for the greater community to share in it, but still putting more eggs in the basket security-wise. Developers have reaced agreement, Localization Lab lacks sysadmins, and the both of them want a shared libre platform.

To me it seems only fitting that Hosted Weblate is used, seeing as they also want to carry out changes to the platform, reaping the benefit of having the sysadmin being the same capable person that develops Weblate. The other person i would trust with this now works for Pontoon, and I want to see more response and results out of them before I consider it to be an equal alternative.

AGPL is better for hosted services than GPL, but Pontoon is New BSD, so for me it starts off playing a weaker hand.

The large sum of money going elsewhere, (and we could minutely disagree how grim a place that is), can actually put to good use in building the tools and community libre software translation needs.

Building libre software translation community with the projects it translates is not possible with a non-free, non-working, spying tool in its midst.
Every project can do their part, paying dividends for what translators have put in, and will be able to, by moving now.

The localization lab could add all the projects in its umbrella to the loclab website, by progress, with the supplied widgets.

3 Likes