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

List:       kde-i18n-doc
Subject:    Re: Structure of translation files on Subversion (question for all teams)
From:       Karl Ove Hufthammer <karl () huftis ! org>
Date:       2017-07-22 20:36:17
Message-ID: 83a13b7a-13aa-1734-6abc-677ec55013b3 () huftis ! org
[Download RAW message or body]

Luigi Toscano skreiv 14. juli 2017 23:05:
> Now, let's consider this structure instead:
> <lang>
> --> <messages/docmessages/docs/etc>
> -----> <repository name>
> --------> <po files of the repository>
>
> where repository is kconfig, okular, kile, etc
>
> The question is: would this structure be acceptable for you? Please consider
> the following answers, and it would be nice to have answers from a relevant
> group of languages :)
>
> a) I don't care, fine by me/my language team, I can get the logical module
> from sysadmin/repo-metadata.git;
> b) yes, but in our team we need to see some structure, like which set of
> repositories are shipped together, but if the website shows this it's fine;
> c) absolutely not, our team need the current structure because <please write a
> reason>;

For the Norwegian Nynorsk team, we don't need the *current* structure, 
but we would really prefer *some* structure, e.g. a somewhat small 
number folders with a bunch of files in each instead of a large number 
of folders with only a single file in each.

I'm not sure what your proposals a) and b) really entails. For example, 
how would the current ‘kde-workspace' module look?

And how would the ‘playground-*' modules be handled? They're mostly 
filled with junk (lots of stuff that haven't been updated for 5+ years, 
don't compile, and never will be revived), and do not warrant 
translations. Having them mixed in with the other applications and 
libraries (which *do* ‘deserve' translations) would be very confusing.

The same is, at least partially, true for the ‘kdereview' module. Even 
though this was meant as a temporary holding place, with a two week 
review period

   https://community.kde.org/Policies/Application_Lifecycle

it currently hold several applications that haven't been updated for 
years (the oldest template files were generated in 2013). Having these 
mixed in with regular applications makes the translators work filtering 
them out harder. (And we cannot just look at the POT generation dates, 
as there are several ‘normal' applications (and especially .desktop 
files) that haven't seen string changes for years.)

-- 
Karl Ove Hufthammer
[prev in list] [next in list] [prev in thread] [next in thread]