[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-i18n-doc
Subject:    Re: Web Translation tool
From:       Carl Schwan <carl () carlschwan ! eu>
Date:       2024-03-27 13:07:00
Message-ID: 3002636.MYZNlBPI1G () fedora
[Download RAW message or body]

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




[prev in list] [next in list] [prev in thread] [next in thread]