> -----Original Message-----
> From: Julian Foad [mailto:julianf...@apache.org]
> Sent: maandag 13 maart 2017 11:53
> To: Stefan Kueng <tortoise...@gmail.com>
> Cc: Subversion Development <dev@subversion.apache.org>
> 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
