The current website is difficult to have a blog in because it is hard to update frequently due to security concerns. @Coffee @NicoAlt and I have briefly discussed splitting out the blog/TWIF into a standalone site, like blog.f-droid.org. I think it could make a lot of sense.
The open questions that I see are:
- what kind of site? gitlab pages? discourse? wordpress? something else?
- how should the translations be handled? weblate? directly translated Markdown files submitted via Merge Request? something else?
@critdroid @idmpub @mesnevi @kingu
I would vote for using a static page again. However, it does not need and might should not be made using the same software as the current website (Jekyll) as we’ve noted that it not quite the best software coming to internationalization (although @hans and @uniqx are currently working on this).
Going the Python way, there’s Pelican and Lektor, with the latter soon being used by Tor and calling itself “Multilingual” (We can speak multiple languages and allow you to easily create localized websites.). Another popular option seems to be Hugo, a framework calling itself “The world’s fastest framework for building websites” and being used by at least Transportr, run by a F-Droid core member. It might also get used by Briar in future.
Whatever we choose, I would deploy it using GitLab CI/GitLab pages, given the fact that we soon have our own CI runners.
I personally think that the community readers of the blog are “geeks” who can easily read / write english texts and I would prefer that all our efforts / time go closer to “end users” by developing great softwares and providing a translated “client” quality app (the server side is also more for techies).
That’s not the point, translations are done by volunteers (like me) that mostly can’t just
develop great software, but they can contribute translations.
Not sure why you need to bring this up, whatever framework might just need to allow for translations, it’s not like @uniqx or @hans will start to translate…
@uniqx and I looked into Lektor. It has a nice editor GUI, is written
in Python, and should support Weblate integration well. But it has a
custom file format, which is disappointing, so the existing files would
have to be converted.
Hugo has the same file format, has native localization support, and is
actively developed and widely used. It is written in Go, which is sad.
But hopefully it would just work, so we wouldn’t have to touch Go code.
Is it possible to create a gitlab project “blog-f-droid” with a project wiki where every logged-in-gitlab-user have write permission to?
This could be used as the proposed wiki.
I am using github-projekt-wikis for my github-projects for this. I do not have experiences with gitlab for this.
yup, that’s totally possible and works for me.
I’m slightly leaning towards jekyll at this point. It means we can reuse all the materials we already have, most importantly the F-Droid theme.
I looked into Hugo, and its template syntax is absolutely horrible and breaks my brain. For example, it has extremely weird ideas about case sensitivity, where variables are sort of case insensitive, but case matters, and the casing for the exact same variable needs to be different when using it in different contexts.
On the up side, Hugo is Fast with a capital F.
I thought that Hugo could use the Liquid/Jinja2 templates that Jekyll
does? Or at least there seems to be an option to use Liquid with Hugo.
It does, and combines that with its own syntax for referencing page variables and such.
FYI, work on this is underway, mostly being done by @Coffee, partially funded by a grant F-Droid got for improving localization workflows.
@Coffee set up the prototype website here: https://fdroid.gitlab.io/fdroid-news/
Now, we are looking for feedback on the best translation workflow for the news section. From what I’ve seen, blogs/news sites usually do translation based on accepting full document translation directly, rather than through a service like Weblate. Does that make sense for us?
I’m partial to having this under Weblate as well, but then again I won’t bother translating any TWIF.
Not sure how it should work! Could you explain a little what’s the plan?
I’ll fetch the complete #twif document from where and submit my translation whereto? What do I need for it? Who gets access? Who beats whom in case of different translators and versions?
Btw, atm your link only provides an English version.
@critdroid: The new repo lives here: https://gitlab.com/fdroid/fdroid-news
One possible workflow is to submit PRs directly. The other is that we copy the scripts from the main website and do the translation via weblate in the exact same way.
I’d ask for people to not submit translations for this site yet, while the transition is not complete. The articles still go to the main website, where they are translated, and I’d hate for people to do redundant (and mutually incompatible) translation work.
Yes, good point. If we go the direct submission route, we’d need some out-of-band way to coordinate the translations.
Having strings be editable in Weblate is a point of inquiry not to be missed.
even for long form texts? I’ve heard from other translators that merge
requests make more sense for blog posts. They are almost never changed
or updated, and they are one big block of narrative text. Plus, blog
posts can be skipped and the blog doesn’t look incomplete.
Especially for long form texts. Breaking them down to single sentences would do wonders.
The blog is almost never changed because it is almost never translated, which is an issue of figuring out what the latest blogpost is. It is too daunting to start doing it all when the source is so riddled with errors. Fixing those via MRs would take the best part of a year?
With editable fields in Weblate it doesn’t break the flow of translation, and is very easy to do. You also get nice and quick access to do searches for concurrency.
Yes, if everyone was a wizard all of that is possible, but no.
Blog posts are rarely changed, the blog itself has frequent new
additions. Also, about errors in the source string, for something like
blog posts, it is usually not worth fixing the grammar and spelling
errors in them. Most of them are only read around the time they are
posted, so it is wasted effort to make updates and then no one ever sees
those updates. This is the opposite of app strings, which are
frequently seen no matter how old they are.
I’ve gotten quite a bit of feedback from other translators on the topic
of blog posts. I’ve heard that doing them broken down into lines rarely
makes sense. So far, I think @kingu is the only one I’ve heard who says
@larjona it would be great to have your feedback on this topic, as
bits.debian.org maintainer, a translator, and an fdroid contributor.
@larjona pointed out that the Debian Handbook has a well defined workflow that we can learn from, and maybe just use directly:
Here’s our conversation:
I think the blog articles shouldn’t be split in paragraph/sentences. If they are upload to weblate, hey should go in one piece. I don’t know if that is possible in weblate
I’m wondering whether it is still valuable to have it in Weblate if we are handling translations as a full text, or just ask for direct merge requests
That depends on if our translators use git or mail to commit/Send PR/send the file by mail. If they mostly like translate via web, then weblate is the way to go. If there is a good page explaining the how to, maybe it’s not “needed” to use weblate.
but given that webalte is all about getting to 100%, I think that translators might get frustrated at seeing that the blog is always far away from 100% translated
I don’t know. There are big documentation projects using weblate for some languages (e.g. the Debian Handbook). I think it depends on the persons. I personally prefer weblate for short strings, but weblate also allows to download the file, work offline and upload the file so…¯_(ツ)_/¯ I think the workflow of the Debian handbook is good: propose to use git, and if some language/team want to use weblate, they move there and a note is left in the repo “this language uses weblate in https://url”.