Web Translation tool
Carl Schwan
carl at carlschwan.eu
Wed Mar 27 13:07:00 GMT 2024
On Wednesday, March 27, 2024 12:12:01 AM CET Albert Astals Cid wrote:
> El dijous, 21 de març de 2024, a les 0:49:17 (CET), Carl Schwan va escriure:
> > Hello everyone,
> >
> > A few days ago, I suddenly got the motivation to look into building a
> > small
> > web tool for our translation designed in a way that it can coexist with
> > the
> > current workflow. It was also an excuse to learn a bit of Rust 🦀 and to
> > refresh my knowledge on VueJs :)
> >
> > The idea is to have a simple website allowing people to login with their
> > gitlab account and then let them edit the po files with a web ui. For KDE
> > developers/translators, it would allow to either publish their changes
> > immediately to SVN or save their changes inside the database to allow
> > someone else to review them. For non kde developers, only after a review
> > would the change be allowed to be merged in SVN.
>
> How would that work when we rename files (doesn't happen a lot, but it does
> happen from time to time).
My plan is to just run `svn pull` regularly. The list of language and
components in the web interface is computed at run time from the directory
structures with a small cache for the translation stats of the po files.
> > Here is the repository: https://invent.kde.org/carlschwan/webl10n/
> >
> > Currently this is still very much in progress but I can already login with
> > gitlab, load all po files in the summit directory in SVN,
>
> summit is an unofficial way of doing translations
> do you plan to support the regular way?
Maybe, but if I do I want to try to hide the complexity of the regular workflow
as much as possible by ensuring the translator in the web interface only see a
single lists of string to translate and when submitting a change, ensure that
the change is committed to all the relevant branches instead of just trunk or
stable.
> Or do you think we should all move to summit?
This would be ideal but I can dream ;) I complained in the past that with the
"regular" workflow often translations exists but is either only available in
the trunk branch or stable branch. At least for NeoChat before moving to Gear,
we often ended up with a tarball containing less translations than that was
actually translated because the branches were not automatically synchronized
and this was with announcing the string freeze weeks before to this mailing
list.
> Looks good :)
>
> How easy would it be to deploy in a very limited manner so that interested
> folks can have a look at the thing in a live scennario?
I will likely host a simple (and read only) instance with a few languages
enabled soon. Deployment is fortunately very easy since it's just a simple
binary + 3 static files behind a basic nginx reverse proxy.
> > Before I invest more time on it, it would be good to have some feedback on
> > the idea and if there is someone among you who is familiar with Rust or
> > VueJs, help is also welcome.
>
> As others have mentioned maintainability is a potential concern, how big is
> the codebase? How easy do you think it'd be to hack on for a total newbie?
The code base is still very small but it will likely grow as more features are
added and edge cases handled. The rust part is a very simple with just a bit
of glue between serde (to serialize/deserialize JSON) and diesel (to
serialize/deserialize to the DB). It's my first non-trivial rust app, so I try
to keep the code readable instead of optimizing for speed. The code should not
be too hard to understand when coming from a C++ background.
The vue/js part is a bit more complex for people unfamiliar with Vue, but
basically most pages are just a for loop over data fetched from a REST API.
Ideally the whole website could also replace https://l10n.kde.org/ so that we
don't need to maintain two similar systems.
> I'm guessing having access to the Translation Memory (i.e. how the word has
> been translated in other instances) wouldn't hurt.
yep, not my biggest priority for now but long term we indeed need that.
Carl
> Cheers,
> Albert
>
> > Cheers,
> > Carl
More information about the kde-i18n-doc
mailing list