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

List:       kde-i18n-doc
Subject:    Re: Web Translation tool
From:       Łukasz Wojniłowicz <lukasz.wojnilowicz () gmail ! com>
Date:       2024-04-05 15:16:57
Message-ID: 20240405171657.612f5698 () luklap ! workgroup
[Download RAW message or body]

Interesting. Where does that idea with changing the translation for
"font" came from? Care to explain?

Cheers,
Łukasz

On Wed, 3 Apr 2024 16:27:27 +0200
"Josep M. Ferrer" <txemaq@saragata.net> wrote:

> El 27/3/24 a les 11:20, Carl Schwan ha escrit:
> > On Friday, March 22, 2024 11:46:23 PM CET Josep M. Ferrer wrote:
> >
> > Thanks for the really helpful information  
> >> Sorry, I don't know Rust nor VueJs, so I can't help with
> >> programming tasks. But I can give you some feedback:
> >>
> >> - In this stage, this tool only works with summit environment, but
> >> I estimate that only 50% or less of KDE translation teams work with
> >> summit. It can be possible to use the usual branches
> >> (stable/trunk) for non-summit teams?  
> > I could add support for non-summit workflow, through this will add
> > some complexity both in term of code as well as in the UX. But is
> > there a reason why some teams don't use the summit workflow? Having
> > only one version of a file to manage sounds easier.  
> 
> At first glance, summit seems a good idea. But, it adds a complexity 
> level on the translation workflow. If translators use Lokalize, it
> can handle two branches without effort, like summit does. This is
> useful for making changes between branches: for example, we (Catalan
> team) has adopted a new translation for "font" but only in Plasma 6,
> using the legacy translation in Plasma 5. Of course this can be done
> in summit, but is more complex.
> 
> At the end, the question is where we want the complexity level: on
> the translation workflow (summit) or on the translation tool?
> 
> Thanks!
> 
> Josep M. Ferrer
> 
> [...]
[prev in list] [next in list] [prev in thread] [next in thread]