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?
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.
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.
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?
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.
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.
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
otherwise.
@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: @larjona:
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
@larjona:
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
@larjona:
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ā.
