OK - I was thinking about a new i18n component as well, so we're pretty
much in agreement.
My discussion about the branch structure was more to do with whether
we'd have a permanent i18n shadow branch for each release, that would be
under continuous integration, so translators could work independently of
code committers. However, I'm happy to revisit that again when there's
actually a need :)
Jim.
On 13/09/2013 19:11, David Roldán Martínez wrote:
Hi,
Thanks for the pointing. I'll consider it next time.
Regarding to the managment, I think the better is to include language
bundles together with the main release, once i18n current branch has
been merged. With the latter we'll have the main code base almost free
of i18n bugs.
I also think useful a new Jira component named "Internationalization"
so that each time someone finds any i18n, will create a ticket. If
they are not translations, you can assign them to me by default.
For translations, we can create a new Jira ticket per language and
release. Once the corresponding language bundle has been committed
we'll be able to track it by the ticket number.
Hope this helps. A debate about this would be highly constructive.
Cheers,
David
El 13/09/2013 19:02, "Jim Procter" <[email protected]
<mailto:[email protected]>> escribió:
Hi David.
On 13/09/2013 12:46, David Roldán Martínez wrote:
> I've just committed a short tutorial about how to i18n your
code. It's
> available at src/doc/i18n.html and you'll be able to access it at
> Release_2_8_1_Branch_i18n branch.
>
> Any feedback will be highly appreciated.
thanks so much for putting this documentation in. I've pushed a tiny
tweak since we've tried to standardise capitalisation of the project
name as 'Jalview', rather than 'JalView'.
With regard to managing multiple translations, how do you think this
will work ? My feeling is it's most straightforward to keep an _i18n
branch for each of the release branches, since translations will occur
in parallel to patches in each release, and we'll make the i18n
version
available by default on the download links on the website.
e.g.
master
\__Release_Branch_X_Y_Z
|\_ Release_Branch_X_Y_Z_i18n
\_ { patch_branches }
If that sounds sane, then I'll instrument our build system so we
have a
'release_i18n' and 'nextrel_i18n' build for the current release
and the
one currently in beta. I'm also open to discussion if having both an
i18n and a non-i18n build will confuse things too much.
Jim.
_______________________________________________
Jalview-dev mailing list
[email protected] <mailto:[email protected]>
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev
_______________________________________________
Jalview-dev mailing list
[email protected]
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev
_______________________________________________
Jalview-dev mailing list
[email protected]
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev
