Note that not only LINGUAS file is a pain to add new languages... Makefile
file for documentation is even more difficult to parse as it's not always
in the same way, and it's needed to add a new language for documentation.
This case should be also considered
Cheers!
2018-09-06 10:00 GMT+02:00
>
> Of course, if there is any problem with a translation commit you can
> always ask this list and we will help you ;-)
Right, the goal is to not break on pre-merge though. But since this seems
quite rare to happen... it's probably not a big deal.
To add more weigh into this, recently I also had
rks, but I don't
>>> consider it be neccesary for translations. It could also generate a
>>> high-traffic for maintainers and delay translators daily work.
>>>
>>> Best regards
>>>
>>> (1) - https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh
t;> high-traffic for maintainers and delay translators daily work.
>>
>> Best regards
>>
>> (1) - https://github.com/dmustieles/gnome_scripts/blob/master/gttk.sh
>>
>> 2018-09-04 9:18 GMT+02:00 Carlos Soriano :
>>
>>> Also, it would be good to know
2018-09-04 9:45 GMT+02:00 Carlos Soriano :
> Yeah... on the other hand I think most of FOSS projects do it this way
> nowadays, at least in things like GitHub, etc. Another thing to consider is
> that translationa can break the code, maybe a good option is that
> translations need to pass CI
t; modules, so I needed Git access.
>>>>
>>>> About merge requests I don't know exactly how it works, but I don't
>>>> consider it be neccesary for translations. It could also generate a
>>>> high-traffic for maintainers and delay translators daily work.
>>&g
Also, it would be good to know if merge requests would be appropriate for
this, instead of pure git access.
On Tue, 4 Sep 2018 at 09:16, Carlos Soriano wrote:
> Hello all,
>
> Recently we had a bit of scramble with the release notes and some
> translators not having git access to
Hello all,
Recently we had a bit of scramble with the release notes and some
translators not having git access to it.
If I remember correctly translators are encouraged to not push directly and
use Dammed Lies instead, if I remember correctly doing otherwise is
unsupported.
However, some
Carlos Soriano :
> Also, it would be good to know if merge requests would be appropriate for
> this, instead of pure git access.
>
> On Tue, 4 Sep 2018 at 09:16, Carlos Soriano wrote:
>
>> Hello all,
>>
>> Recently we had a bit of scramble with the release notes and s
te for
>> this, instead of pure git access.
>>
>> On Tue, 4 Sep 2018 at 09:16, Carlos Soriano wrote:
>>
>>> Hello all,
>>>
>>> Recently we had a bit of scramble with the release notes and some
>>> translators not having git access to it.
Le 06. 09. 18 à 10:00, Carlos Soriano a écrit :
...
Also, another thing I'm taking into account here is that there is a
strong desire by some maintainers to prevent any commit to go directly
to master by using GitLab's protected branches feature (not because of
translators, but generally).
On Tue, Sep 4, 2018 at 9:30 AM Claude Paroz wrote:
> However, there are some cases where Damned Lies is not yet able to push
> *new* translations.
>
Another case that you forgot about and which I also forgot about so far
when replying to this topic is figures. We don’t have a way to upload
Claude,
Em ter, 4 de set de 2018 às 04:30, Claude Paroz escreveu:
>
> Note that there are more and more modules also using LINGUAS files for
> docs, so this issue should be less important in the future. If the
> release-notes build could be changed to use a LINGUAS file, it would be
> great too.
Le 04. 09. 18 à 09:16, Carlos Soriano a écrit :
Hello all,
Recently we had a bit of scramble with the release notes and some
translators not having git access to it.
If I remember correctly translators are encouraged to not push directly
and use Dammed Lies instead, if I remember correctly
14 matches
Mail list logo