Hi all,
As we look at sharing portions of our UI with the Katelo project, one thing that has come up is that we use different internationalization libraries. I wanted to share what I've found and solicit feedback on how we should proceed.
Right now, we use the built-in i18n gem and Rails functionality. Katello uses gettext_i18n_rails[1]. There are a few key differences that keep them from being interchangeable. They have flat .po files and translate text by running something like #{_("Some string to translate")}, versus our #{t("some.string.with.dots")} with nested yaml.
I do think that their method has a few advantages: * They use .po files, which should work seamlessly with Zanata. Our * language files seem to take some manual effort to import to/export * form Zanata. * As flat files, their files are less likely to have duplication. We * have pools.pools as "Pools", but "breadcrumbs.pools" is also "Pools". * (As an arbitrary example.) This isn't the end of the world, though. * We would gain similarity with our sister project, and could see * benefits such as being able to borrow their Javascript i18n * implementation (!).
Of course, there are also some disadvantages: * Changing our libraries would be a lot of work that I really don't look * forward to. * gettext_i18n_rails is another dependency we'd have to add. (Though * it's already packaged, since Katello has been using it for a long * time.)
Right now, the only place this matters is in a couple copyright-type strings in the footer, so it seems like an exorbitantly huge amount of work just for that. But I think there's also benefit in switching to something consistent. The question to me is whether it's worth the large switching cost. Anyone want to weigh in?
-- Matt
On Fri, Apr 20, 2012 at 11:27:34AM -0400, Matt Wagner wrote:
Hi all,
As we look at sharing portions of our UI with the Katelo project, one thing that has come up is that we use different internationalization libraries. I wanted to share what I've found and solicit feedback on how we should proceed.
Right now, we use the built-in i18n gem and Rails functionality. Katello uses gettext_i18n_rails[1]. There are a few key differences that keep them from being interchangeable. They have flat .po files and translate text by running something like #{_("Some string to translate")}, versus our #{t("some.string.with.dots")} with nested yaml.
I do think that their method has a few advantages:
- They use .po files, which should work seamlessly with Zanata. Our
- language files seem to take some manual effort to import to/export
- form Zanata.
- As flat files, their files are less likely to have duplication. We
- have pools.pools as "Pools", but "breadcrumbs.pools" is also "Pools".
- (As an arbitrary example.) This isn't the end of the world, though.
- We would gain similarity with our sister project, and could see
- benefits such as being able to borrow their Javascript i18n
- implementation (!).
Of course, there are also some disadvantages:
- Changing our libraries would be a lot of work that I really don't look
- forward to.
- gettext_i18n_rails is another dependency we'd have to add. (Though
- it's already packaged, since Katello has been using it for a long
- time.)
Right now, the only place this matters is in a couple copyright-type strings in the footer, so it seems like an exorbitantly huge amount of work just for that. But I think there's also benefit in switching to something consistent. The question to me is whether it's worth the large switching cost. Anyone want to weigh in?
-- Matt
My off-the-cuff opinion is that we can defer this until it becomes a real nuisance. We've got enough to do...
--H
On Fri, Apr 20, 2012 at 03:52:02PM -0400, Hugh Brock wrote:
My off-the-cuff opinion is that we can defer this until it becomes a real nuisance. We've got enough to do...
I initially withheld my opinion, but I mostly agree. I started investigating it as a potential blocker for the converged UI work. It ended up not being a blocker, but by the time I determined that, I had found some incidental benefits we'd get if we switched. But if we thought it was a worthwhile endeavor, I think now would be the time, since it would potentially be very disruptive further into a sprint.
-- Matt
On 04/20/2012 05:27 PM, Matt Wagner wrote:
I do think that their method has a few advantages:
- They use .po files, which should work seamlessly with Zanata. Our
- language files seem to take some manual effort to import to/export
- form Zanata.
- As flat files, their files are less likely to have duplication. We
- have pools.pools as "Pools", but "breadcrumbs.pools" is also "Pools".
- (As an arbitrary example.) This isn't the end of the world, though.
Perhaps a quicker interim solution would be to automate Jozef's process to migrate these translations for use in Zanata?
How long would writing a rake task to convert our language files to po's take? (or vice-versa).
Might be simpler / quicker than changing the backend all together, could be contributed upstream, and would save us time in the long run (no need to manually run these steps every time).
-Mo
On Tue, Apr 24, 2012 at 11:02:07AM +0200, Mo Morsi wrote:
On 04/20/2012 05:27 PM, Matt Wagner wrote:
I do think that their method has a few advantages:
- They use .po files, which should work seamlessly with Zanata. Our
- language files seem to take some manual effort to import to/export
- form Zanata.
- As flat files, their files are less likely to have duplication. We
- have pools.pools as "Pools", but "breadcrumbs.pools" is also "Pools".
- (As an arbitrary example.) This isn't the end of the world, though.
Perhaps a quicker interim solution would be to automate Jozef's process to migrate these translations for use in Zanata?
How long would writing a rake task to convert our language files to po's take? (or vice-versa).
Might be simpler / quicker than changing the backend all together, could be contributed upstream, and would save us time in the long run (no need to manually run these steps every time).
That's not a bad idea. Although this feature started out because of the differences between Katello and Aeolus; the ease of future conversions was sort of an incidental benefit. (Though one worth considering.) I think that, if we do end automating some of the conversion (I can't speak to how involved that would be; that's Jozef's specialty), it doesn't really have to occur now.
Is it safe to say that the conclusion of looking at I18n vs. gettext_i18n_rails is that we do not wish to switch libraries? I think that is what was implied here, and it does match what I have come to believe. I figured I should check before closing the task as such, though...
-- Matt
On Thursday 26 April 2012 16:56:56 Matt Wagner wrote:
On Tue, Apr 24, 2012 at 11:02:07AM +0200, Mo Morsi wrote:
On 04/20/2012 05:27 PM, Matt Wagner wrote:
I do think that their method has a few advantages:
- They use .po files, which should work seamlessly with Zanata. Our
- language files seem to take some manual effort to import to/export
- form Zanata.
- As flat files, their files are less likely to have duplication. We
- have pools.pools as "Pools", but "breadcrumbs.pools" is also "Pools".
- (As an arbitrary example.) This isn't the end of the world, though.
+1
Perhaps a quicker interim solution would be to automate Jozef's process to migrate these translations for use in Zanata?
How long would writing a rake task to convert our language files to po's take? (or vice-versa).
For "automation" I'm using gem I18n-translators-tools, so converting YML->PO and next the export to zanata is easy. Conversion of translated PO files to YML is not working properly. Result YML file needs to be edited. (I try only this gem for converting PO to YML, maybe other tool could convert files better ?).
Might be simpler / quicker than changing the backend all together, could be contributed upstream, and would save us time in the long run (no need to manually run these steps every time).
That's not a bad idea. Although this feature started out because of the differences between Katello and Aeolus; the ease of future conversions was sort of an incidental benefit. (Though one worth considering.) I think that, if we do end automating some of the conversion (I can't speak to how involved that would be; that's Jozef's specialty), it doesn't really have to occur now.
For now I'm using my own script for fixing converted files (po->yml) via gem, but the last time i found that it didnt fix all issues.
Is it safe to say that the conclusion of looking at I18n vs. gettext_i18n_rails is that we do not wish to switch libraries? I think that is what was implied here, and it does match what I have come to believe. I figured I should check before closing the task as such, though...
-- Matt
As Jay's proposed me for publishing wiki's info of our i18n process, we could put some info up on this wiki page https://www.aeolusproject.org/redmine/projects/aeolus/wiki/Internationalizat...
Generaly I like the idea to convert to gettext for using PO file as default as Zanata and Katello. All depends on how much time will be spent to achieve fully change.
If we plan it properly (not needed to do right now) we will be able to do it fast.
-- Jozef
aeolus-devel@lists.fedorahosted.org