i18n?

[Christopher Bertels]

Hi,

are there any plans on doing some internationalization?  If not, would
people like to have something like this, now that I have mentioned it? ;)

I guess something yaml-based could work, there are some good libraries
out there afaik.

Why this came to my mind: I usually write mails in german and english
and have done a custom patch to check for the german word for
"attachment" to warn me before sending an email, if I haven't yet
added an attachment to a composed mail. This obviously works for
english right now, but I wanted to have a similar feature in german.
Since adding language specific options all over the code really isn't
the right way, maybe having some kind of language packs would be
nice. I could take care of some german translation (and I suppose I'm
not the only one on this list ;))

Cheers,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203


_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[William Morgan-4]

Reformatted excerpts from Christopher Bertels's message of 2009-09-30:
> are there any plans on doing some internationalization?  If not, would
> people like to have something like this, now that I have mentioned it?

I have no immediate plans personally, but I would love to have this in
Sup.

> I guess something yaml-based could work, there are some good libraries
> out there afaik.

There is a Ruby-Gettext package, which we already use for other reasons.
I think this is probably the best thing to start with, unless it turns
out to be too hard to use, in which case we could consider a custom
solution.

http://www.yotabanana.com/hiki/ruby-gettext.html

> I could take care of some german translation (and I suppose I'm not
> the only one on this list ;))

I know we have a fair amount of German and French representation on the
list, and that's probably representative of the user population in
general. So you should have an appreciative audience.
--
William <wmorgan-sup@...>
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Christopher Bertels]

Excerpts from William Morgan's message of Do Okt 01 18:44:43 +0200 2009:
> I have no immediate plans personally, but I would love to have this in
> Sup.

Alright, good to know.

> There is a Ruby-Gettext package, which we already use for other reasons.
> I think this is probably the best thing to start with, unless it turns
> out to be too hard to use, in which case we could consider a custom
> solution.
>
> http://www.yotabanana.com/hiki/ruby-gettext.html

Cool, I'll have a look at it.

Another reason for adding this would be that for example gpg's output
is different for me (in german) than what sup expects. So trust-paths
for example aren't recognized by default, since the regular expression
in crypto.rb only looks for english output. I fixed this for myself
but I figured it would make more sense to put this kind of stuff to a
central location.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203


_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Christopher Bertels]

Excerpts from William Morgan's message of Do Okt 01 18:44:43 +0200 2009:
> I have no immediate plans personally, but I would love to have this in
> Sup.

Ok, great!

> There is a Ruby-Gettext package, which we already use for other reasons.
> I think this is probably the best thing to start with, unless it turns
> out to be too hard to use, in which case we could consider a custom
> solution.
>
> http://www.yotabanana.com/hiki/ruby-gettext.html

Thanks, I'll have a look at it.

Btw, another reason for adding something like this would be that sup
depends on an english version of gpg. For checking a trust-path, for
example, it uses a regular expression that checks for a certain output
of gpg (in english).  Since I have a german version, this obviously
doesn't work (I had to patch it for my needs).  I guess there probably
are more things where different languages could play a role, so
putting it in a central, well-defined location makes sense.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[William Morgan-4]

Reformatted excerpts from Christopher Bertels's message of 2009-10-01:
> Another reason for adding this would be that for example gpg's output
> is different for me (in german) than what sup expects. So trust-paths
> for example aren't recognized by default, since the regular expression
> in crypto.rb only looks for english output.

It will be interesting to see how gettext handles the case of regular
expressions (which is also probably what you want for the "attachment"
detector). If it's not natural to wedge regexen into gettext, we should
consider a custom solution.
--
William <wmorgan-sup@...>
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Christopher Bertels]

Please excuse my double posting. Sup crashed after sending a message.
I have the exception log attached.
Seems like it has a problem with the sent.mbox and wants me to
      sup-sync --changed sup://sent

I switched from ferret to xapian today and the error clearly happens there.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203

--- NoMethodError from thread: poll after loading inbox
undefined method `[]' for nil:NilClass
/home/bakkdoor/projekte/ruby/sup/lib/sup/xapian_index.rb:558:in `mkterm'
/home/bakkdoor/projekte/ruby/sup/lib/sup/xapian_index.rb:373:in `find_docid'
/home/bakkdoor/projekte/ruby/sup/lib/sup/xapian_index.rb:379:in `find_doc'
/home/bakkdoor/projekte/ruby/sup/lib/sup/xapian_index.rb:389:in `get_entry'
/home/bakkdoor/projekte/ruby/sup/lib/sup/xapian_index.rb:75:in `build_message'
/usr/lib/ruby/1.8/monitor.rb:242:in `synchronize'
/home/bakkdoor/projekte/ruby/sup/lib/sup/xapian_index.rb:398:in `synchronize'
/home/bakkdoor/projekte/ruby/sup/lib/sup/xapian_index.rb:75:in `build_message'
/home/bakkdoor/projekte/ruby/sup/lib/sup/util.rb:520:in `send'
/home/bakkdoor/projekte/ruby/sup/lib/sup/util.rb:520:in `method_missing'
/home/bakkdoor/projekte/ruby/sup/lib/sup/poll.rb:94:in `do_poll'
/home/bakkdoor/projekte/ruby/sup/lib/sup/poll.rb:151:in `each_message_from'
/home/bakkdoor/projekte/ruby/sup/lib/sup/source.rb:104:in `each'
/home/bakkdoor/projekte/ruby/sup/lib/sup/util.rb:560:in `send'
/home/bakkdoor/projekte/ruby/sup/lib/sup/util.rb:560:in `__pass'
/home/bakkdoor/projekte/ruby/sup/lib/sup/util.rb:547:in `method_missing'
/home/bakkdoor/projekte/ruby/sup/lib/sup/poll.rb:139:in `each_message_from'
/home/bakkdoor/projekte/ruby/sup/lib/sup/poll.rb:93:in `do_poll'
/home/bakkdoor/projekte/ruby/sup/lib/sup/poll.rb:81:in `each'
/home/bakkdoor/projekte/ruby/sup/lib/sup/poll.rb:81:in `do_poll'
/home/bakkdoor/projekte/ruby/sup/lib/sup/poll.rb:80:in `synchronize'
/home/bakkdoor/projekte/ruby/sup/lib/sup/poll.rb:80:in `do_poll'
/home/bakkdoor/projekte/ruby/sup/lib/sup/util.rb:520:in `send'
/home/bakkdoor/projekte/ruby/sup/lib/sup/util.rb:520:in `method_missing'
/home/bakkdoor/projekte/ruby/sup/lib/sup/modes/poll-mode.rb:15:in `poll'
/home/bakkdoor/projekte/ruby/sup/lib/sup/poll.rb:48:in `poll'
/home/bakkdoor/projekte/ruby/sup/lib/sup/util.rb:520:in `send'
/home/bakkdoor/projekte/ruby/sup/lib/sup/util.rb:520:in `method_missing'
/home/bakkdoor/projekte/ruby/sup/bin/sup:196
/home/bakkdoor/projekte/ruby/sup/lib/sup.rb:77:in `reporting_thread'
/home/bakkdoor/projekte/ruby/sup/lib/sup.rb:75:in `initialize'
/home/bakkdoor/projekte/ruby/sup/lib/sup.rb:75:in `new'
/home/bakkdoor/projekte/ruby/sup/lib/sup.rb:75:in `reporting_thread'
/home/bakkdoor/projekte/ruby/sup/bin/sup:196
/home/bakkdoor/projekte/ruby/sup/lib/sup/modes/thread-index-mode.rb:669:in `call'
/home/bakkdoor/projekte/ruby/sup/lib/sup/modes/thread-index-mode.rb:669:in `__unprotected_load_threads'
/home/bakkdoor/projekte/ruby/sup/lib/sup/modes/thread-index-mode.rb:610:in `call'
/home/bakkdoor/projekte/ruby/sup/lib/sup/modes/thread-index-mode.rb:610:in `load_n_threads_background'
/home/bakkdoor/projekte/ruby/sup/lib/sup.rb:77:in `reporting_thread'
/home/bakkdoor/projekte/ruby/sup/lib/sup.rb:75:in `initialize'
/home/bakkdoor/projekte/ruby/sup/lib/sup.rb:75:in `new'
/home/bakkdoor/projekte/ruby/sup/lib/sup.rb:75:in `reporting_thread'
/home/bakkdoor/projekte/ruby/sup/lib/sup/modes/thread-index-mode.rb:608:in `load_n_threads_background'
/home/bakkdoor/projekte/ruby/sup/lib/sup/modes/thread-index-mode.rb:679:in `__unprotected_load_threads'
(eval):12:in `load_threads'
/home/bakkdoor/projekte/ruby/sup/bin/sup:196

_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Rich Lane]

Excerpts from Christopher Bertels's message of Thu Oct 01 14:33:03 -0400 2009:
> undefined method `[]' for nil:NilClass
> /home/bakkdoor/projekte/ruby/sup/lib/sup/xapian_index.rb:558:in `mkterm'

What commit is your tree at?
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Christopher Bertels]

Excerpts from William Morgan's message of Do Okt 01 20:24:57 +0200 2009:
> It will be interesting to see how gettext handles the case of regular
> expressions (which is also probably what you want for the "attachment"
> detector). If it's not natural to wedge regexen into gettext, we should
> consider a custom solution.

Hmm. Well I started working on something simple based on yaml files.
I looked at gettext but that seemed a little weird to me.  Since
Ruby's yaml module supports regular expressions, this is a plus point,
I guess. It worked with the attachments example.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203


_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Christopher Bertels]

I've uploaded what I've done so far to
http://www.gitorious.org/~bakkdoor/sup/bakkdoors-clone/trees/i18n 
You can get it via git here:
git://gitorious.org/~bakkdoor/sup/bakkdoors-clone.git (branch: i18n)

Please tell me what you think. I know it's pretty simple but for now I
guess that's all we need. Or am I missing something?  

One thing I wanted to add as well is, that if there is no translation
found for a different language, it will default to the english version
(instead of returning nil).
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Christopher Bertels]

I think I've translated most of sup's UI-related part (translating
error messages doesn't seem like a good idea, since we really don't
want multilingual bug-reports and exception logs...) I'd like to hear
some feedback and/or opinions/suggestions and would like to see it
integrated into sup. I'll add more translations, if I find anything I
havent missed yet and that is part of the user interface.

Cheers,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[William Morgan-4]

Hi Christopher,

Reformatted excerpts from Christopher Bertels's message of 2009-10-05:
> I'd like to hear some feedback and/or opinions/suggestions and would
> like to see it integrated into sup. I'll add more translations, if I
> find anything I havent missed yet and that is part of the user
> interface.

This looks great. A couple comments:

1. I would prefer that uppercase substitution symbols made lowercase.
The uppercase seems weird and un-Rubyish to me.

2. I think it would be nice to have a simple module along the lines of:

  module M17n
    def m s, o={}; I18n[m, o] end
  end

and to have that be the primary entry point when you want a translated
string. Then classes can include that module if they want m17n support,
and instead of writing

  I18n["text", { :var => value }]

you can have

  m("text", :var => value)

which is a little easier to read, IMO.

3. Should we call it m17n instead of i18n? I think that might be a
little more accurate. Perhaps too nitpicky. What do you think?

4. A finishing touch would be to have sup-config ask the user what
language they are interested in.
--
William <wmorgan-sup@...>
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Christopher Bertels]

Excerpts from William Morgan's message of Di Okt 06 17:38:39 +0200 2009:
> This looks great. A couple comments:

Cool, good to know you like it!

> 1. I would prefer that uppercase substitution symbols made lowercase.
> The uppercase seems weird and un-Rubyish to me.

Ok, sounds good. I thought making them uppercase to let them be more
distict from the rest of the string but since we surround them by #{}
as in Ruby, you're making a good point here. I'll change that.

> 2. I think it would be nice to have a simple module along the lines of:
>
>   module M17n
>     def m s, o={}; I18n[m, o] end
>   end
>
> and to have that be the primary entry point when you want a translated
> string. Then classes can include that module if they want m17n support,
> and instead of writing
>
>   I18n["text", { :var => value }]
>
> you can have
>
>   m("text", :var => value)
>
> which is a little easier to read, IMO.

Same here. Think this is nicer, too.

> 3. Should we call it m17n instead of i18n? I think that might be a
> little more accurate. Perhaps too nitpicky. What do you think?

I couldn't care less about the name - but I guess m17n fits better,
since it's just multilingualization. :)

> 4. A finishing touch would be to have sup-config ask the user what
> language they are interested in.

Alright, cool. I'll add that as well, once I have the rest changed & working.

Cheers,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203


_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Christopher Bertels]

OK, I've changed it as mentioned.
See my previously mentioned gitorious branch.

Cheers,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Christopher Bertels]

Just wondering, if anyone is still interested in this, since no one has replied yet.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203


_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Fabio Riga]

Excerpts from Christopher Bertels's message of mar ott 20 14:33:35 +0200 2009:
> Just wondering, if anyone is still interested in this, since no one has replied
> yet.
Well, I'm really interested, but I'm just a user. I could only make
Italian translation, but how? Is it a normal gettext .po file? What I
have to do?

Cheers,
Fabio
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Guillaume Quintard]

> Excerpts from Christopher Bertels's message of mar ott 20 14:33:35 +0200 2009:
> Well, I'm really interested, but I'm just a user. I could only make
> Italian translation, but how? Is it a normal gettext .po file? What I
> have to do?

Same here, with french translation.
Sorry for the late reply.

--
Guillaume
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Christopher Bertels]

Excerpts from Fabio Riga's message of Mi Okt 21 14:29:59 +0200 2009:
> Well, I'm really interested, but I'm just a user. I could only make
> Italian translation, but how? Is it a normal gettext .po file? What I
> have to do?

Get my sup clone git repository at gitorious:

$ git clone git://gitorious.org/~bakkdoor/sup/bakkdoors-clone.git

Then, checkout the i18n branch.

$ cd bakkdoors-clone
$ git checkout i18n

Then have a look at the m17n folder. You should find a de.yaml and
en.yaml file.  They are for german and english translations. You can
create your own translation files in there. For example, fr.yaml for
french or it.yaml for italian.  Have a look at en.yaml to see, what
the original texts are (in english) and come up with your own
translation. That's basically it. Then, if you have sup set up to run
from that branch, you can set within your sup config file
(~/.sup/config.yaml) to use any language, e.g.:

:language: de

for german. Sup will then look into the m17n folder for a file called "de.yaml"

I hope that helped.

Cheers,
Christopher.
--
================================
Christopher Bertels
http://www.adztec-independent.de
GPG Key ID: 0x2345b203


_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Tero Tilus-2]

Excerpts from 's message of pe loka 02 15:52:47 +0300 2009:
> Please tell me what you think.

Why not default to the english strings as translation keys and
fallback to key itself in case of missing translation?  This has imo
several advantages.  You can go grep the source using what you see in
sup UI (instead of first greping language yaml).  Adding new strings
is cumbersome with (mostly unnecessary) key indirection.  Code is more
readable when messages are inlined.  If you change a string a check of
translations is forced (there is no translation for the changed
version).  Most translation workflow tools expect this kind of
behavior.

--
Tero Tilus ## 050 3635 235 ## http://tero.tilus.net/
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[Fabio Riga]

Excerpts from Tero Tilus's message of ven ott 23 09:00:21 +0200 2009:
> Excerpts from 's message of pe loka 02 15:52:47 +0300 2009:
> > Please tell me what you think.
>
> Why not default to the english strings as translation keys and
> fallback to key itself in case of missing translation?  This has imo
> several advantages.  You can go grep the source using what you see in
> sup UI (instead of first greping language yaml).

Well, I finally read the code and I agree with Tero. I also think that the
use of gettext will be simpler for both developer and translator. In
this way, every time a developer add a new string he need to write it
twice, or another developer has to hack it. Instead with gettext the
developer write his string, surrounded with _() or n_() and he's done
(tell me, if I'm wrong).

Furthermore people used to .po files (like me) will know what to do and
are already provided with tools for that purpose (i.e. Vim :-) ).

Can anyone explain me where and why a translated string in the UI should be
searchable with a regular expression? (Maybe this question is due to the
fact that I still don't understand sup internals...)

Cheers,
Fabio
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk

[William Morgan-4]

Reformatted excerpts from Fabio Riga's message of 2009-10-23:
> Well, I finally read the code and I agree with Tero. I also think that
> the use of gettext will be simpler for both developer and translator.
> In this way, every time a developer add a new string he need to write
> it twice, or another developer has to hack it. Instead with gettext
> the developer write his string, surrounded with _() or n_() and he's
> done (tell me, if I'm wrong).

Tero's comment wasn't about gettext, as far as I understand it. There
are Ruby gettext bindings but they look like a pain in the ass to use,
and it's pretty trivial to replace it a language like Ruby.

> Furthermore people used to .po files (like me) will know what to do
> and are already provided with tools for that purpose (i.e. Vim :-) ).

That is a downside, definitely.

> Can anyone explain me where and why a translated string in the UI should be
> searchable with a regular expression? (Maybe this question is due to the
> fact that I still don't understand sup internals...)

I believe he was thinking about something like git grep. You see a weird
message displayed by Sup, you want to find the code that's generating
it, you can git grep the source for the message directly.
--
William <wmorgan-sup@...>
_______________________________________________
sup-talk mailing list
sup-talk@...
http://rubyforge.org/mailman/listinfo/sup-talk