Hi all,
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.
Cheers,
David
Hi David.
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.
···
On 13/09/2013 12:46, 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” <jprocter@compbio.dundee.ac.uk> 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
Jalview-dev@jalview.org
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev
Hi,
···
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,
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 <jprocter@compbio.dundee.ac.uk>
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,
DavidEl 13/09/2013 19:02, “Jim Procter” <jprocter@compbio.dundee.ac.uk> 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
Jalview-dev@jalview.org
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev_______________________________________________ Jalview-dev mailing list [Jalview-dev@jalview.org](mailto:Jalview-dev@jalview.org) [http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev](http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev)
Jalview-dev mailing list
Jalview-dev@jalview.org
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev
Hi David.
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.
hmm. this would require a different architecture for Jalview's git repository - since commit privileges are granted at the level of branches and top level repository access. Read on below...
Besides, you won't have to
maintain two branches simplifying relase management, as i18n will a be
core functionality.
that was always the plan
Lets think about this another way. Jalview's source is going to be separated into components in the near future - to yield a set of modular compilation blocks. At the same time, I think it would also be a good idea to separate the i18n translation packs, and the Jalview help into separate components that would build jars and and OSGi bundles for adding to the runtime classpath. That would mean that translators could have commit access to translation packs independently of core code modules (which would still include core i18n).
I foresee something like the following set of git repositories:
jalview_apis.git
jalview_core.git
jalview_help.git
jalview_cli.git
jalview_lite.git
jalview_desktop.git
jalview_i18n.git
The complication here is that Jalview has multiple components that involve i18n - cli (headless jalview), desktop (the application you've i18n'ed) and lite (the web applet). I still plan on a single build mechanism, and synchronization across repositories will be done with git submodules. Do you think that will be managable for translators ?
Jim.
ps, As an aside here, are there any web or desktop applications that allow language packs to be edited in a user friendly manner ? I'd be happy to install something on *.jalview.org that allowed translators to log in and work directly on translations.
···
On Tue Sep 17 11:37:47 2013, David Roldán Martínez wrote:
Hi,
If this scheme will be manageable for translators or not depends on each translators skills. 
Anyway, the easier the process would be, the better for translator (and for not translators).
For editing language bundles I sometimes use Eclipse, though my preferred editor is NotePad. Call me traditional…or even freak but it’s faster because the eclipse plugin has to render file content in a friendly UI and this takes time.
Cheers,
David
···
2013/9/17 Jim Procter <foreveremain@gmail.com>
Hi David.
On Tue Sep 17 11:37:47 2013, David Roldán Martínez wrote:
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.
hmm. this would require a different architecture for Jalview’s git
repository - since commit privileges are granted at the level of
branches and top level repository access. Read on below…Besides, you won’t have to
maintain two branches simplifying relase management, as i18n will a be
core functionality.
that was always the planLets think about this another way. Jalview’s source is going to be
separated into components in the near future - to yield a set of
modular compilation blocks. At the same time, I think it would also be
a good idea to separate the i18n translation packs, and the Jalview
help into separate components that would build jars and and OSGi
bundles for adding to the runtime classpath. That would mean that
translators could have commit access to translation packs independently
of core code modules (which would still include core i18n).I foresee something like the following set of git repositories:
jalview_apis.git
jalview_core.git
jalview_help.git
jalview_cli.git
jalview_lite.git
jalview_desktop.git
jalview_i18n.gitThe complication here is that Jalview has multiple components that
involve i18n - cli (headless jalview), desktop (the application you’ve
i18n’ed) and lite (the web applet). I still plan on a single build
mechanism, and synchronization across repositories will be done with
git submodules. Do you think that will be managable for translators ?Jim.
ps, As an aside here, are there any web or desktop applications that
allow language packs to be edited in a user friendly manner ? I’d be
happy to install something on *.jalview.org that allowed translators to
log in and work directly on translations.
Jalview-dev mailing list
Jalview-dev@jalview.org
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-dev