translations

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

translations

Stefan Kueng
Hi,

Since the new conflict resolver API offer a lot of strings to be used in
an UI, I'm wondering about the translations of those strings.

I remember there was a discussion about two years ago about using a web
based translation tool for Subversion (e.g.
http://translationproject.org/), but that discussion got to no real
decision.
For TSVN we use transifex (https://www.transifex.com/) which is free for
open source projects. Works quite well - it updates the new strings
automatically from our repository pot file.

Even if Subversion does not move to use such a web based tool: how about
providing the source pot file in the repository which should be updated
frequently so translators can use that file without having to install
and parse the whole svn source?

I'm bringing this up again since I noticed that the existing
translations are very old and outdated. And since TSVN is fully
translated in many languages, the new conflict resolver UI would still
show the English strings since they now come from the svn lib.

Stefan

--
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Daniel Shahaf-2
Stefan Kueng wrote on Sat, Feb 04, 2017 at 17:13:06 +0100:
> I remember there was a discussion about two years ago about using a web
> based translation tool for Subversion (e.g. http://translationproject.org/),
> but that discussion got to no real decision.
> For TSVN we use transifex (https://www.transifex.com/) which is free for
> open source projects. Works quite well - it updates the new strings
> automatically from our repository pot file.

ASF has a Pootle instance: https://translate.apache.org/

> Even if Subversion does not move to use such a web based tool: how about
> providing the source pot file in the repository which should be updated
> frequently so translators can use that file without having to install and
> parse the whole svn source?

I'd certainly be willing to consider changes to make people's workflows
easier, but what reason do we have to project that changing the workflow
will result in more translation work getting done?  No existing or
prospective translator has asked dev@ to change our workflow.

(To clarify, I'm not objecting; simply seeking clarification.)

For reference, the process today is:
.
    svn co https://svn.apache.org/repos/asf/subversion/trunk svn-trunk
    cd svn-trunk
    tools/po/po-update.sh
    <edit>
    <send a patch>

> I'm bringing this up again since I noticed that the existing translations
> are very old and outdated. And since TSVN is fully translated in many
> languages, the new conflict resolver UI would still show the English strings
> since they now come from the svn lib.

Well, of course more translations would be a good thing.  Perhaps some
of the TSVN translators could translate Subversion itself as well?  It
would be great if they could join this thread.

Cheers,

Daniel
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Stefan Kueng


On 04.02.2017 18:16, Daniel Shahaf wrote:

> Stefan Kueng wrote on Sat, Feb 04, 2017 at 17:13:06 +0100:
>> I remember there was a discussion about two years ago about using a web
>> based translation tool for Subversion (e.g. http://translationproject.org/),
>> but that discussion got to no real decision.
>> For TSVN we use transifex (https://www.transifex.com/) which is free for
>> open source projects. Works quite well - it updates the new strings
>> automatically from our repository pot file.
>
> ASF has a Pootle instance: https://translate.apache.org/
>
>> Even if Subversion does not move to use such a web based tool: how about
>> providing the source pot file in the repository which should be updated
>> frequently so translators can use that file without having to install and
>> parse the whole svn source?
>
> I'd certainly be willing to consider changes to make people's workflows
> easier, but what reason do we have to project that changing the workflow
> will result in more translation work getting done?  No existing or
> prospective translator has asked dev@ to change our workflow.

Well, to even have prospective translators, there would have to be at
least *some* indication on the website that svn can/should be translated.
And always remember that translators usually are users, not developers.

In TSVN, we rarely have a translator send any email to the list - they
just sign up on the website and start translating, without contacting us
first.

>
> (To clarify, I'm not objecting; simply seeking clarification.)
>
> For reference, the process today is:
> .
>     svn co https://svn.apache.org/repos/asf/subversion/trunk svn-trunk
>     cd svn-trunk
>     tools/po/po-update.sh
>     <edit>
>     <send a patch>

the problem here is the third line: that won't work on Windows, which
I'd say most svn users use.

So why not at least have a developer do that once every week and then
the translators would only have to checkout/update the subversion/po dir
and start translating from there.

>> I'm bringing this up again since I noticed that the existing translations
>> are very old and outdated. And since TSVN is fully translated in many
>> languages, the new conflict resolver UI would still show the English strings
>> since they now come from the svn lib.
>
> Well, of course more translations would be a good thing.  Perhaps some
> of the TSVN translators could translate Subversion itself as well?  It
> would be great if they could join this thread.

I'm sure they would, if it was as easy as it is with TSVN.

Stefan

--
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Andreas Stieger
In reply to this post by Stefan Kueng
On 04/02/17 17:13, Stefan Kueng wrote:
> [...]I'm wondering about the translations of those strings.

Several points on this:

#1 Working with Pootle works well, both ways. There is just a bit of a
coordination effort. That coordination needs to be figured out more
urgently than the actual tool.

#2 Help output in UI strings.

This is A LOT of insane frustrating work. Every time the help output of
a command changes even a little bit, the complete string needs to be
re-checked. It needs to be adjusted for spacing and justification. And
at that point you really need to walk the svn code history to adjust the
translation, there is no way to get a stable community of translators on
that level.

Note how you need to maintain the command line switches in several places?
* command line logic code
* subcommand help output
* translations of same
* (subversion book)
There are tools for keeping this stuff synchronized, e.g. autogen. That
would then also compile into help, man, docbook, chm and whatnot.

Andreas



Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Stefan Kueng


On 05.02.2017 12:21, Andreas Stieger wrote:

> On 04/02/17 17:13, Stefan Kueng wrote:
>> [...]I'm wondering about the translations of those strings.
>
> Several points on this:
>
> #1 Working with Pootle works well, both ways. There is just a bit of a
> coordination effort. That coordination needs to be figured out more
> urgently than the actual tool.
>
> #2 Help output in UI strings.
>
> This is A LOT of insane frustrating work. Every time the help output of
> a command changes even a little bit, the complete string needs to be
> re-checked. It needs to be adjusted for spacing and justification. And
> at that point you really need to walk the svn code history to adjust the
> translation, there is no way to get a stable community of translators on
> that level.

What does that have to do with my suggestion of using a web based tool
or otherwise make it easier for translators?
Yes, translating is a lot of work and a lot of things have to be
considered, but please let's keep this discussion on track and deal with
these other problems in other discussions. Otherwise this discussion
will go nowhere again, like two years ago.

Stefan

--
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Julian Foad-6
In reply to this post by Stefan Kueng
Stefan Kueng wrote:

> Daniel Shahaf wrote:
>> Stefan Kueng wrote on Sat, Feb 04, 2017 at 17:13:06 +0100:
>>> I remember there was a discussion about two years ago about using a web
>>> based translation tool for Subversion (e.g.
>>> http://translationproject.org/),
>>> but that discussion got to no real decision.
>>> For TSVN we use transifex (https://www.transifex.com/) which is free for
>>> open source projects. Works quite well - it updates the new strings
>>> automatically from our repository pot file.
>>
>> ASF has a Pootle instance: https://translate.apache.org/
>>
>>> Even if Subversion does not move to use such a web based tool: how about
>>> providing the source pot file in the repository which should be updated
>>> frequently so translators can use that file without having to install and
>>> parse the whole svn source?
[...]
> So why not at least have a developer do that once every week and then
> the translators would only have to checkout/update the subversion/po dir
> and start translating from there.

Speaking without knowledge of exactly what's required, and also not
volunteering myself to do it, but just as a developer wanting to see
this task get done and therefore wanting to make life easier for the
volunteers who do it...

This sounds like a no-brainer to me. Of course we would want to do that.
So let's get this moving by doing this easy step first -- just checking
in the .pot -- right now, and then improve:

1. check it in now, manually, and try to remember to update it
sometimes, manually;

2. automate the updating of it (in a daily builder?)

3. use Pootle or whatever (discuss how, after 1. is done)

Checking in the .pot sounds like a perfectly good exception to the
general rule "don't check in generated code".

Previously I said let's write to the existing translators to involve
them with any decision to move to a system like Pootle. I still think we
should. But that's not relevant for 1. and 2.

Any objections or down-sides that I've missed?

- Julian
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Daniel Shahaf-2
In reply to this post by Stefan Kueng
Stefan Kueng wrote on Sat, Feb 04, 2017 at 18:27:01 +0100:
> In TSVN, we rarely have a translator send any email to the list - they just
> sign up on the website and start translating, without contacting us first.

Currently, translators must be committers and as such are required to
have ICLAs on file.  I think waiving this requirement would require
legal@'s approval.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Daniel Shahaf-2
In reply to this post by Julian Foad-6
Julian Foad wrote on Sun, Feb 05, 2017 at 15:56:31 +0100:
> This sounds like a no-brainer to me. Of course we would want to do that. So
> let's get this moving by doing this easy step first -- just checking in the
> .pot -- right now, and then improve:
>
> 1. check it in now, manually, and try to remember to update it sometimes,
> manually;
>
> 2. automate the updating of it (in a daily builder?)
>

Without voicing an opinion about *whether* we should keep .pot in
version control...

I think that *if* we do so, then we should do step #2 directly, without
#1 first, for two reasons:

a. If we do #1 and not #2, we will probably end up with an outdated .pot
in HEAD.  (And possibly in 1.10.0.tar.gz)  Humans simply aren't as good
at running cron jobs as crond is ;-).

b. Doing #2 directly is very low overhead.

Cheers,

Daniel

> 3. use Pootle or whatever (discuss how, after 1. is done)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Daniel Shahaf-2
In reply to this post by Stefan Kueng
Stefan Kueng wrote on Sun, Feb 05, 2017 at 15:28:25 +0100:

>
>
> On 05.02.2017 12:21, Andreas Stieger wrote:
> >On 04/02/17 17:13, Stefan Kueng wrote:
> >>[...]I'm wondering about the translations of those strings.
> >
> >Several points on this:
> >
> >#1 Working with Pootle works well, both ways. There is just a bit of a
> >coordination effort. That coordination needs to be figured out more
> >urgently than the actual tool.
> >
> >#2 Help output in UI strings.
> >
> >This is A LOT of insane frustrating work. Every time the help output of
> >a command changes even a little bit, the complete string needs to be
> >re-checked. It needs to be adjusted for spacing and justification. And
> >at that point you really need to walk the svn code history to adjust the
> >translation, there is no way to get a stable community of translators on
> >that level.
>
> What does that have to do with my suggestion of using a web based tool or
> otherwise make it easier for translators?

You identified a problem (translations don't happen) and suggested that
changing the translators workflow would fix it.  Andreas identified
a frustrating aspect of the translation workflow that would not be
addressed by moving to Transifex or Pootle or whatnot.  That's perfectly
on topic to your underlying concern.

That is: perhaps what stops people from translating is the set of
strings we give them, rather than the format we present them those
strings in.

Cheers,

Daniel

> Yes, translating is a lot of work and a lot of things have to be considered,
> but please let's keep this discussion on track and deal with these other
> problems in other discussions. Otherwise this discussion will go nowhere
> again, like two years ago.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Daniel Shahaf-2
Daniel Shahaf wrote on Sun, Feb 05, 2017 at 19:55:15 +0000:

> Stefan Kueng wrote on Sun, Feb 05, 2017 at 15:28:25 +0100:
> >
> >
> > On 05.02.2017 12:21, Andreas Stieger wrote:
> > >On 04/02/17 17:13, Stefan Kueng wrote:
> > >>[...]I'm wondering about the translations of those strings.
> > >
> > >Several points on this:
> > >
> > >#1 Working with Pootle works well, both ways. There is just a bit of a
> > >coordination effort. That coordination needs to be figured out more
> > >urgently than the actual tool.
> > >
> > >#2 Help output in UI strings.
> > >
> > >This is A LOT of insane frustrating work. Every time the help output of
> > >a command changes even a little bit, the complete string needs to be
> > >re-checked. It needs to be adjusted for spacing and justification. And
> > >at that point you really need to walk the svn code history to adjust the
> > >translation, there is no way to get a stable community of translators on
> > >that level.

> That is: perhaps what stops people from translating is the set of
> strings we give them, rather than the format we present them those
> strings in.

Further thought about this: it sounds to me like the best way to handle
small changes in long strings (such as 'svn help merge') would be to
present the differences in wdiff3 format, where the '<<<' hunk is in the
local language and the '|||' and '===' hunks are in English.

The wdiff format would see through rewrapping (I routinely use 'wdiff -d'
to review documentation patches; it's a life saver), and the 'diff3'
format perfectly suits the problem of porting "upstream trunk" (English
strings) changes to a "child branch" (localized strings).

https://subversion.apache.org/docs/release-notes/1.9#three-way-conflict-markers

Cheers,

Daniel
(sorry for multiposting)
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Stefan
In reply to this post by Daniel Shahaf-2
On 2/5/2017 20:55, Daniel Shahaf wrote:

> Stefan Kueng wrote on Sun, Feb 05, 2017 at 15:28:25 +0100:
>>
>> On 05.02.2017 12:21, Andreas Stieger wrote:
>>> On 04/02/17 17:13, Stefan Kueng wrote:
>>>> [...]I'm wondering about the translations of those strings.
>>> Several points on this:
>>>
>>> #1 Working with Pootle works well, both ways. There is just a bit of a
>>> coordination effort. That coordination needs to be figured out more
>>> urgently than the actual tool.
>>>
>>> #2 Help output in UI strings.
>>>
>>> This is A LOT of insane frustrating work. Every time the help output of
>>> a command changes even a little bit, the complete string needs to be
>>> re-checked. It needs to be adjusted for spacing and justification. And
>>> at that point you really need to walk the svn code history to adjust the
>>> translation, there is no way to get a stable community of translators on
>>> that level.
>> What does that have to do with my suggestion of using a web based tool or
>> otherwise make it easier for translators?
> You identified a problem (translations don't happen) and suggested that
> changing the translators workflow would fix it.  Andreas identified
> a frustrating aspect of the translation workflow that would not be
> addressed by moving to Transifex or Pootle or whatnot.  That's perfectly
> on topic to your underlying concern.
>
> That is: perhaps what stops people from translating is the set of
> strings we give them, rather than the format we present them those
> strings in.
>
FWIW: I agree with Stefan here. Atm it looks like it's quite a challenge
for someone stepping by to contribute a simple translation fix. In all
projects I'm aware of where translations get good quality directly from
volunteers, the major point is: accessibility for anybody to contribute
easily to the translation without much work and a very low learning curve.

The only way projects achieved this to my knowledge is to provide some
straight forward, simple and easy to use (preferably even without the
requirement of registration) web front end.

I fully agree also with Andreas that this is causing kind of problems
for things like layouts, but I'd also argue that going the step and
provide easier means to contribute to translations via a web front-end
should be done first, and then we can further improve upon that.

Regards,
Stefan



smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Julian Foad-6
In reply to this post by Daniel Shahaf-2
Daniel Shahaf wrote:

> Julian Foad wrote on Sun, Feb 05, 2017 at 15:56:31 +0100:
>> This sounds like a no-brainer to me. Of course we would want to do that. So
>> let's get this moving by doing this easy step first -- just checking in the
>> .pot -- right now, and then improve:
>>
>> 1. check it in now, manually, and try to remember to update it sometimes,
>> manually;
>>
>> 2. automate the updating of it (in a daily builder?)
>
> Without voicing an opinion about *whether* we should keep .pot in
> version control...
>
> I think that *if* we do so, then we should do step #2 directly, without
> #1 first, for two reasons:
>
> a. If we do #1 and not #2, we will probably end up with an outdated .pot
> in HEAD.  (And possibly in 1.10.0.tar.gz)  Humans simply aren't as good
> at running cron jobs as crond is ;-).
>
> b. Doing #2 directly is very low overhead.

Fair point.

Any volunteers to figure out the details and do it?

(Details include things like: ideally every time we commit a code change
that changes the messages, we'd update the .pot in the same commit, so
we should always run it along with "make" and "make check"; but "make
locale-gnu-pot" updates all the source line number references even if
the messages themselves haven't changed, and we probably don't want that
amount of churn.)

- Julian
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Stefan Kueng
In reply to this post by Daniel Shahaf-2


On 05.02.2017 20:55, Daniel Shahaf wrote:

> Stefan Kueng wrote on Sun, Feb 05, 2017 at 15:28:25 +0100:
>>
>>
>> On 05.02.2017 12:21, Andreas Stieger wrote:
>>> On 04/02/17 17:13, Stefan Kueng wrote:
>>>> [...]I'm wondering about the translations of those strings.
>>>
>>> Several points on this:
>>>
>>> #1 Working with Pootle works well, both ways. There is just a bit of a
>>> coordination effort. That coordination needs to be figured out more
>>> urgently than the actual tool.
>>>
>>> #2 Help output in UI strings.
>>>
>>> This is A LOT of insane frustrating work. Every time the help output of
>>> a command changes even a little bit, the complete string needs to be
>>> re-checked. It needs to be adjusted for spacing and justification. And
>>> at that point you really need to walk the svn code history to adjust the
>>> translation, there is no way to get a stable community of translators on
>>> that level.
>>
>> What does that have to do with my suggestion of using a web based tool or
>> otherwise make it easier for translators?
>
> You identified a problem (translations don't happen) and suggested that
> changing the translators workflow would fix it.  Andreas identified
> a frustrating aspect of the translation workflow that would not be
> addressed by moving to Transifex or Pootle or whatnot.  That's perfectly
> on topic to your underlying concern.

Not really. I didn't say that changing the workflow would fix the whole
problem, but make it easier for translators to even start.
The problem Andreas identified is there whether we make it easier for
translators to get started or not.

> That is: perhaps what stops people from translating is the set of
> strings we give them, rather than the format we present them those
> strings in.

And here's the problem: we don't even give them the strings to
translate! They have to install many tools to even get those strings in
the first place.

So I suggest we first come to an agreement on how to provide the strings
to translators without having them create those themselves, then in a
next step maybe set up a web based tool and *then* discuss on how to
help translators with issues like indentation.

If we start discussing everything at once, I fear we'll get nowhere again.


Stefan

--
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Julian Foad-6
In reply to this post by Stefan Kueng
On 2017-02-04, Stefan Kueng wrote:
> [...]
> I remember there was a discussion about two years ago about using a web
> based translation tool for Subversion (e.g.
> http://translationproject.org/), but that discussion got to no real
> decision.
> For TSVN we use transifex (https://www.transifex.com/) which is free for
> open source projects. Works quite well - it updates the new strings
> automatically from our repository pot file.

I just noticed we are already in Apache's Pootle:

   https://translate.apache.org/projects/Subversion/

with German as the only translation language so far.

Are we using Pootle correctly and efficiently for the German
translation? What do we have to do, to start using it more fully?

For a first step, could we usefully do something like transmit the .pot
file to Pootle instead of checking it in to our source tree? Would that
be better?

- Julian
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Andreas Stieger
Hi,

> I just noticed we are already in Apache's Pootle:
>
>    https://translate.apache.org/projects/Subversion/
>
> with German as the only translation language so far.

I set this up during my last translation round.

> Are we using Pootle correctly and efficiently for the German
> translation?

It worked sufficiently well for strings that have no special formatting requirements. It also worked well for out-of-band changes, e.g. merging items translated locally with those translated in Pootle.

For anything that includes non-trivial help output and special formatting, I found it to be cumbersome.

> What do we have to do, to start using it more fully?

Regular local scan of trunk, uploading it to Pootle, translating/review, and commit into source.
 
> For a first step, could we usefully do something like transmit the .pot
> file to Pootle instead of checking it in to our source tree? Would that
> be better?

You would not use the .pot but the .po, so as to not loose existing translations.
For other translations: setting them up in Pootle, I did not want to presume that other po maintainers would want to do that.

Pootle has automation opportunities of scanning the code base, have not explored.

Is that something we want to kick off for the next release?

Andreas
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations

Branko Čibej
On 09.02.2017 14:16, Andreas Stieger wrote:
> You would not use the .pot but the .po, so as to not loose existing translations.
> For other translations: setting them up in Pootle, I did not want to presume that other po maintainers would want to do that.
>
> Pootle has automation opportunities of scanning the code base, have not explored.
>
> Is that something we want to kick off for the next release?

It wouldn't hurt to bring Subversion into the 20th century, at least as
far as translations are concerned. :)

I can help with any scripting but can't promise to lead this effort ...
NoTimeTM.

-- Brane
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations (let's use Transifex or Pootle)

Julian Foad-6
> Andreas Stieger wrote:
>> [Pootle] worked sufficiently well for strings that have no special
>> formatting requirements. It also worked well for out-of-band changes,
>> e.g. merging items translated locally with those translated in Pootle.
>>
>> For anything that includes non-trivial help output and special
>> formatting, I found it to be cumbersome.
[...]
>> You would not use the .pot but the .po, so as to not loose existing
>> translations.
>> For other translations: setting them up in Pootle, I did not want to
>> presume that other po maintainers would want to do that.
>>
>> Pootle has automation opportunities of scanning the code base, have not
>> explored.
>>
>> Is that something we want to kick off for the next release?

Andreas, thanks for your thoughts. It sounds like your overall
experience of using Pootle was that it was useful but not great.

Also I see that OpenOffice is the *only* project really using Apache's
Pootle: other than that and Subversion (German only), there is just
JMeter (French only) and two projects that have no major activity.

So the major reason I assumed we should use it -- because I assumed it
was the standard tool for Apache projects -- evaporates. How about we
use transifex (https://www.transifex.com/) then, because it's what
TortoiseSVN is using?

Branko Čibej wrote:
> It wouldn't hurt to bring Subversion into the 20th century, at least as
> far as translations are concerned. :)

+1

> I can help with any scripting but can't promise to lead this effort ...
> NoTimeTM.

Thanks! (And me too.)

- Julian
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations (buildbot to update translatable strings)

Julian Foad-5
In reply to this post by Stefan Kueng
Stefan K, trying to help push this forward...

We have consensus to do something about automatically providing updates
to translatable strings. We need some help to fill in the details and
actually do it.

 From my perspective, it looks like we should:

* Instantiate a bot (buildbot) that will...
   - do we have a volunteer?

   * Check out the trunk (and any configured branches).

   * Run 'make po-update'.

   * (?) Upload the updated 'subversion.pot' and/or '*.po' files
     to services including Pootle and Transifex.
     - how exactly should it upload to Pootle?
     - how exactly should it upload to Transifex?

   * (?) Commit the updated 'subversion.pot' and/or '*.po' files.
     - which files? when (see below)?

* Activate a Transifex.com account for Subversion.
   - how? can you do it?

Re committing: I think we should rate-limit these commits to once per
day, and should not commit when there are no real changes to the
translatable strings but only changes in the source line number
reference comments.

An alternative to committing would be to upload these files to some
place where translators can fetch them. Somewhere on apache.org and/or
if the Pootle and/or Transifex services make these files easily
available then that's fine, we can point at those, no need to commit.
   - Do they? What are the URLs?

Can you and others help fill in the details?

- Julian


On 04/02/17, Stefan Kueng wrote:

> [...]
> I remember there was a discussion about two years ago about using a web
> based translation tool for Subversion (e.g.
> http://translationproject.org/), but that discussion got to no real
> decision.
> For TSVN we use transifex (https://www.transifex.com/) which is free for
> open source projects. Works quite well - it updates the new strings
> automatically from our repository pot file.
>
> Even if Subversion does not move to use such a web based tool: how about
> providing the source pot file in the repository which should be updated
> frequently so translators can use that file without having to install
> and parse the whole svn source?
> [...]

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: translations (buildbot to update translatable strings)

Bert Huijben-5


> -----Original Message-----
> From: Julian Foad [mailto:[hidden email]]
> Sent: maandag 13 maart 2017 11:53
> To: Stefan Kueng <[hidden email]>
> Cc: Subversion Development <[hidden email]>
> Subject: Re: translations (buildbot to update translatable strings)
>
> Stefan K, trying to help push this forward...
>
> We have consensus to do something about automatically providing updates
> to translatable strings. We need some help to fill in the details and
> actually do it.
>
>  From my perspective, it looks like we should:
>
> * Instantiate a bot (buildbot) that will...
>    - do we have a volunteer?
>
>    * Check out the trunk (and any configured branches).
>
>    * Run 'make po-update'.

If nobody else steps up, I can handle this part.

>    * (?) Upload the updated 'subversion.pot' and/or '*.po' files
>      to services including Pootle and Transifex.
>      - how exactly should it upload to Pootle?
>      - how exactly should it upload to Transifex?

Also willing to work on this part, after we have that info.

>    * (?) Commit the updated 'subversion.pot' and/or '*.po' files.
>      - which files? when (see below)?
>
> * Activate a Transifex.com account for Subversion.
>    - how? can you do it?
>
> Re committing: I think we should rate-limit these commits to once per
> day, and should not commit when there are no real changes to the
> translatable strings but only changes in the source line number
> reference comments.
>
> An alternative to committing would be to upload these files to some
> place where translators can fetch them. Somewhere on apache.org and/or
> if the Pootle and/or Transifex services make these files easily
> available then that's fine, we can point at those, no need to commit.
>    - Do they? What are the URLs?

I would start with this second scheme... Perhaps even add an option to one of our scripts to fetch the latest version at [build/invoke], for easy testing and committing around releases.

Not sure if we should really start auto commits on our tree...

Don't see a good use for these auto commits on trunk, as that code is seldom used in production...
And I would like to be careful with our release branches, on not creating too many unneeded commits that could be collapsed...

        Bert

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: translations (buildbot to update translatable strings)

Stefan Kueng
In reply to this post by Julian Foad-5


On 13.03.2017 11:52, Julian Foad wrote:

> Stefan K, trying to help push this forward...
>
> We have consensus to do something about automatically providing updates
> to translatable strings. We need some help to fill in the details and
> actually do it.
>
> From my perspective, it looks like we should:
>
> * Instantiate a bot (buildbot) that will...
>   - do we have a volunteer?
>
>   * Check out the trunk (and any configured branches).
>
>   * Run 'make po-update'.
>
>   * (?) Upload the updated 'subversion.pot' and/or '*.po' files
>     to services including Pootle and Transifex.
>     - how exactly should it upload to Pootle?
>     - how exactly should it upload to Transifex?

I don't know about pootle, but Transifex fetches the files itself from a
specified url or urls.
In TSVN, we have the pot file in the repository, and Transifex just
fetches it from there. Not sure about the interval it fetches the files,
but it is fine for TSVN.

>
>   * (?) Commit the updated 'subversion.pot' and/or '*.po' files.
>     - which files? when (see below)?

Transifex provides a script which can be run to update the translated po
files from their servers and apply the changes to the local files.
In TSVN we have the translated po files also in the repository so the
build script (which also builds the installers for the different
languages) has everything ready.

> * Activate a Transifex.com account for Subversion.
>   - how? can you do it?

I suggest that more than just one svn dev signs up there - just one is
dangerous in case of a bus-factor situation.

>
> Re committing: I think we should rate-limit these commits to once per
> day, and should not commit when there are no real changes to the
> translatable strings but only changes in the source line number
> reference comments.

Again, talking about TSVN: we run the transifex script to fetch the
translated po files once a week. For us that's enough.

> An alternative to committing would be to upload these files to some
> place where translators can fetch them. Somewhere on apache.org and/or
> if the Pootle and/or Transifex services make these files easily
> available then that's fine, we can point at those, no need to commit.
>   - Do they? What are the URLs?

Transifex allows to download and upload the po files easily. For TSVN
German, the urls are:
https://www.transifex.com/luebbe/tortoisesvn/trunk-gui/de/download/for_translation/
for the whole po file ready for translation, and there are even urls to
download a po file with only the translated strings in them.


Stefan

--
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest interface to (Sub)version control
    /_/   \_\     http://tortoisesvn.net
12
Loading...