<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">El 27/3/24 a les 11:20, Carl Schwan ha
escrit:<br>
</div>
<blockquote type="cite" cite="mid:38145620.hpaLLnEpJf@fedora">
<pre class="moz-quote-pre" wrap="">On Friday, March 22, 2024 11:46:23 PM CET Josep M. Ferrer wrote:
Thanks for the really helpful information
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">
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?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
<p>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.</p>
<p>At the end, the question is where we want the complexity level:
on the translation workflow (summit) or on the translation tool?</p>
<p>Thanks!</p>
<p>Josep M. Ferrer<br>
</p>
<p>[...]</p>
</body>
</html>