Hi,
And why not to give commit privileges to translators but only to language
bundle files? In this way, translator would be able to work independently
to the rest of committers. Besides, you won't have to maintain two branches
simplifying relase management, as i18n will a be core functionality.
Cheers,
David
2013/9/17 Jim Procter <[email protected]>
> 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]>
> 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]
>> http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev
>>
>
>
> _______________________________________________
> Jalview-dev mailing
> [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
