Created attachment 139185 [details] [review]
Add internationalization

(In reply to comment #0)
> Add some initial calls to dgettext.  Note that we need to use it
> instead of plain gettext since our messages aren't in the default
> translation domain (mutter), because we're a plugin.

Hm... we could take advantage of javascript's dynamicness here...

const Gettext = imports.gettext.textdomain("gnome-shell");

where imports.gettext.textdomain() would be:

function(domain) {
    return { gettext: function(string) { return dgettext(domain, string); },
             ngettext: ...
};

Created attachment 139318 [details] [review]
Add internationalization

Infrastructure for internationalization; hook up intltool, create po/
and po/POTFILES.in.  We need to call bindtextdomain/bind_textdomain_codeset.

Created attachment 139319 [details] [review]
Add calls to gettext for human-visible strings

Add some initial calls to gettext; can't be sure I got them all,
but it should be the vast majority.

Created attachment 139320 [details] [review]
Add test fr translation

Useful to verify that translation infrastructure is working.

Note this bug depends on the gjs changes in bug 589651

It (In reply to comment #3)
> Created an attachment (id=139318) [edit]
> Add internationalization
> 
> Infrastructure for internationalization; hook up intltool, create po/
> and po/POTFILES.in.  We need to call bindtextdomain/bind_textdomain_codeset.

- It's localization not internationalization that you are adding :-)
 
- You don't seem to use intltool at all. Maybe adding intltool should wait and go along with setting up the GConf schemas for translation?

- Patch otherwise looks fine

- Have you checked 'make distcheck'?

(In reply to comment #4)
> Created an attachment (id=139319) [edit]
> Add calls to gettext for human-visible strings
> 
> Add some initial calls to gettext; can't be sure I got them all,
> but it should be the vast majority.

Looks very visually clunk to scatter Gettext.gettext() all over the source code. Any reason not to follow the same conventions as with C?

(In reply to comment #5)
> Created an attachment (id=139320) [edit]
> Add test fr translation
> 
> Useful to verify that translation infrastructure is working.

Looks fine.

(In reply to comment #8)
> (In reply to comment #4)
> > Created an attachment (id=139319) [edit]
> > Add calls to gettext for human-visible strings
> > 
> > Add some initial calls to gettext; can't be sure I got them all,
> > but it should be the vast majority.
> 
> Looks very visually clunk to scatter Gettext.gettext() all over the source
> code. Any reason not to follow the same conventions as with C?

You mean like

const Gettext = imports.gettext.domain('gnome-shell');
const _ = Gettext.gettext;

?

Created attachment 139327 [details] [review]
Add localization

Infrastructure for localization; hook up intltool, create po/
and po/POTFILES.in.  We need to call bindtextdomain/bind_textdomain_codeset.

(In reply to comment #10)
> (In reply to comment #8)
> > (In reply to comment #4)
> > > Created an attachment (id=139319) [edit]
> > > Add calls to gettext for human-visible strings
> > > 
> > > Add some initial calls to gettext; can't be sure I got them all,
> > > but it should be the vast majority.
> > 
> > Looks very visually clunk to scatter Gettext.gettext() all over the source
> > code. Any reason not to follow the same conventions as with C?
> 
> You mean like
> 
> const Gettext = imports.gettext.domain('gnome-shell');
> const _ = Gettext.gettext;

Yeah. (Though see some discussion I added to gjs bug about whether we can put more support in the module there.)

I don't have a strong opinion; calling .gettext doesn't seem particularly onerous to me since we just don't have that many strings in JavaScript right now.  But I'm fine with doing _ if it appears compelling to others.

Pushed using _.

Please ask on gnome-i18n@ list to get listed at
http://l10n.gnome.org/module/gnome-shell/ and also ask translators for translations.