[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 10:20:58
Message-ID: 38145620.hpaLLnEpJf () fedora
[Download RAW message or body]

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.

> - Editor and editor-confirmation should display metadata for translation
> units. Metadata includes translator comments (# ), source code (#:) and
> disambiguation context (msgctxt).  As a plus, it will be very useful
> that a click on the source code will open a new window with the source
> code (from invent.kde.org or similar). Translator comments (# ) should
> be an editable field. Metadata fields are a big help in translation
> workflow because they help to improve quality and consistency of
> translated messages.

I already had msgctxt support, but I will add the translator comments and 
source code location too. 
 
> - Note that in many languages there are some plural forms for each
> translation unit (plural forms depends on language). This requires a
> special handling.

This is now implemented :)

> - Note that there are tags (html, qt, sphinx, etc.) that must be present
> in the original and translated messages. Also, there are entities
> translating documentation. This requires a special handling.

Do we need to do more special handling than just showing the html tags and the 
xml entities as plain text.

> - Editor and editor-confirmation should have a spellchecker for
> translations (as a plus, also for original message to find typos in
> original messages). This will help with spellchecking translated messages.

Spellchecker is luckily provided by the browser and there are multiple browser 
extensions available to improve it :) 

> - Editor and editor-confirmation should have a Memory Translation to
> pick translations from, as Lokalize has currently. This helps
> translation teams to be consistent across all KDE translations.

Yeah this might be a a bit complicated to implement, so it is unlikely to be 
implemented soon.

> On the other hand, I think this tool can be very useful for new
> translators and for established teams, because it hides the complexities
> of SVN to new translators at the beginning, but the established teams
> retain the control over translations, avoiding inconsistencies or
> undesirable changes.
> 
> Of course, I can help you testing this tool.
> 
> Thanks for your work.
> 
> Josep M. Ferrer




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