so I looked on your branch and it seems you translated some portion of
the code. What is done and what is missing? I mean, what was your plan
to move on (I do see "menu translated" commit). Do you want me to
continue with this?
Also in your patch I see this new fastgettext_initializer.rb:
+module FastGettext
module Translation
···
+
+ alias :old_ :_
+
+ def _(key)
+ "X" + old_(key) + "X"
+ end
+ end
+end
I think we could make this optional as it greatly helps to catch
untranslated strings.
Do folks aggree with a new option? Should I go for foreman.yml or env
variable for this (rather development) option? Or would you prefer to
keep this out of the codebase?
I will also implement all the improvements that has been recently merged
to Katello. That is:
a) Using GNU gettext for MO generation (locale/Makefile file) instead
using rubygem-gettext (rake gettext:pack).
b) Using pofilter to catch bad translations (also in the Makefile as a
“make check” target). This is a python application and we could run this
in Jenkins or during the package build.
c) Enabling Transiflex for the project to allow the community to help
with translations.
> Hey Bryan,
>
> so I looked on your branch and it seems you translated some portion of
> the code. What is done and what is missing? I mean, what was your plan
> to move on (I do see "menu translated" commit). Do you want me to
> continue with this?
I was working up the more menu… doing controllers, views, models for
each page. I got as far as the configuration menu.
If you wanted to start at the Dashboard page and move left, we could
meet in the middle.
Also, There is some text in js which I have not gotten to. If you could
find out how katello did this and bring it over it would be great.
>
> Also in your patch I see this new fastgettext_initializer.rb:
>
> +module FastGettext
> + module Translation
> +
> + alias :old_ :_
> +
> + def (key)
> + "X" + old(key) + "X"
> + end
> + end
> +end
>
> I think we could make this optional as it greatly helps to catch
> untranslated strings.
>
> Do folks aggree with a new option? Should I go for foreman.yml or env
> variable for this (rather development) option? Or would you prefer to
> keep this out of the codebase?
I agree, this is a nice way to find misses. n
>
> https://github.com/bkearney/foreman/tree/bkearney/i18n-more
>
> I will also implement all the improvements that has been recently merged
> to Katello. That is:
>
> a) Using GNU gettext for MO generation (locale/Makefile file) instead
> using rubygem-gettext (rake gettext:pack).
>
> b) Using pofilter to catch bad translations (also in the Makefile as a
> "make check" target). This is a python application and we could run this
> in Jenkins or during the package build.
>
> c) Enabling Transiflex for the project to allow the community to help
> with translations.
>
> Opinions?
>
Sounds good. I dont think that foreman is using Makefiles however.
> >Hey Bryan,
> >
> >so I looked on your branch and it seems you translated some portion of
> >the code. What is done and what is missing? I mean, what was your plan
> >to move on (I do see "menu translated" commit). Do you want me to
> >continue with this?
>
> I was working up the more menu… doing controllers, views, models
> for each page. I got as far as the configuration menu.
>
> If you wanted to start at the Dashboard page and move left, we could
> meet in the middle.
>
> Also, There is some text in js which I have not gotten to. If you
> could find out how katello did this and bring it over it would be
> great.
Ok but rather than big bang I would prefer small incremental pull
requests. Would you mind separating the infrastructure commits (the
improved initializer belllow and rename) from the translation commit, so
I can start my own work?
> >Also in your patch I see this new fastgettext_initializer.rb:
> >
> >+module FastGettext
> >+ module Translation
> >+
> >+ alias :old_ :_
> >+
> >+ def (key)
> >+ "X" + old(key) + "X"
> >+ end
> >+ end
> >+end
> >
> >I think we could make this optional as it greatly helps to catch
> >untranslated strings.
> >
> >Do folks aggree with a new option? Should I go for foreman.yml or env
> >variable for this (rather development) option? Or would you prefer to
> >keep this out of the codebase?
>
> I agree, this is a nice way to find misses. n
Opinions?
> Sounds good. I dont think that foreman is using Makefiles however.
Yeah, I want to read opinions. I can picture Ruby community to prefer
Rakefiles over Makefiles, but I assume MO generation would be only used
for packaging.
My plan is to do an extra check and when Foreman is started directly
(e.g. non-RPM installation - either development or production),
fast_gettext would read PO files directly (without need of MO
generation). This would mean users will not need to do any extra steps
to start up Foreman quickly.
···
On Fri, Mar 22, 2013 at 08:03:28AM -0400, Bryan Kearney wrote:
> On 03/22/2013 06:50 AM, Lukas Zapletal wrote:
The turn around may be a bit slow… I have opened up my branch to you.
Why dont we finish up there and then do one pull request into develop…
sound good?
– bk
···
On 03/22/2013 09:24 AM, Lukas Zapletal wrote:
> On Fri, Mar 22, 2013 at 08:03:28AM -0400, Bryan Kearney wrote:
>> On 03/22/2013 06:50 AM, Lukas Zapletal wrote:
>>> Hey Bryan,
>>>
>>> so I looked on your branch and it seems you translated some portion of
>>> the code. What is done and what is missing? I mean, what was your plan
>>> to move on (I do see "menu translated" commit). Do you want me to
>>> continue with this?
>>
>> I was working up the more menu... doing controllers, views, models
>> for each page. I got as far as the configuration menu.
>>
>> If you wanted to start at the Dashboard page and move left, we could
>> meet in the middle.
>>
>> Also, There is some text in js which I have not gotten to. If you
>> could find out how katello did this and bring it over it would be
>> great.
>
> Ok but rather than big bang I would prefer small incremental pull
> requests. Would you mind separating the infrastructure commits (the
> improved initializer belllow and rename) from the translation commit, so
> I can start my own work?
>>> Hey Bryan,
>>>
>>> so I looked on your branch and it seems you translated some portion of
>>> the code. What is done and what is missing? I mean, what was your plan
>>> to move on (I do see "menu translated" commit). Do you want me to
>>> continue with this?
>>
>> I was working up the more menu… doing controllers, views, models
>> for each page. I got as far as the configuration menu.
>>
>> If you wanted to start at the Dashboard page and move left, we could
>> meet in the middle.
>>
>> Also, There is some text in js which I have not gotten to. If you
>> could find out how katello did this and bring it over it would be
>> great.
>
> Ok but rather than big bang I would prefer small incremental pull
> requests. Would you mind separating the infrastructure commits (the
> improved initializer belllow and rename) from the translation commit, so
> I can start my own work?
>
>
>>> Also in your patch I see this new fastgettext_initializer.rb:
>>>
>>> +module FastGettext
>>> + module Translation
>>> +
>>> + alias :old_ :_
>>> +
>>> + def (key)
>>> + "X" + old(key) + "X"
>>> + end
>>> + end
>>> +end
>>>
>>> I think we could make this optional as it greatly helps to catch
>>> untranslated strings.
>>>
>>> Do folks aggree with a new option? Should I go for foreman.yml or env
>>> variable for this (rather development) option? Or would you prefer to
>>> keep this out of the codebase?
>>
>> I agree, this is a nice way to find misses. n
>
> Opinions?
It looks very useful, please add it! I prefer foreman.yml option. But
env variable would also be ok for me.
T.
···
On 03/22/2013 02:24 PM, Lukas Zapletal wrote:
> On Fri, Mar 22, 2013 at 08:03:28AM -0400, Bryan Kearney wrote:
>> On 03/22/2013 06:50 AM, Lukas Zapletal wrote:
Sounds good. I dont think that foreman is using Makefiles however.
Yeah, I want to read opinions. I can picture Ruby community to prefer
Rakefiles over Makefiles, but I assume MO generation would be only used
for packaging.
My plan is to do an extra check and when Foreman is started directly
(e.g. non-RPM installation - either development or production),
fast_gettext would read PO files directly (without need of MO
generation). This would mean users will not need to do any extra steps
to start up Foreman quickly.
