Yes, I understand this. I was just commenting on Amy's answer. Some could have got impression that using initTranslations is dangerous. It is not.
If your extension DOES use translations, then you should use initTranslations, but specify your own gettext domain in metadata.json. Since Amy's extension (which I personally use as well) does not need any translations, you can either change the domain, or, even better, remove initTranslations at all (no translations -- no need in initializing them). The only thing you should not do is having initTranslations for someone else's gettext domain. Vadim. On 05/14/2013 11:31 AM, Bazon Bloch wrote: > > > 2013/5/14 Vadim <va...@dbfin.com <mailto:va...@dbfin.com>> > > @Amy: I do not think that using Convenience.initTranslations() > itself is > the problem. > > > > At least I can confirm that commenting out > "Convenience.initTranslations();" in the init Function let's the > Problem vanish. > > > > I believe in your case the problem is that in metadata.json you have: > > "gettext-domain": "gnome-shell-extensions" > > and that should be a unique gettext domain. If you need standard > translations from "gnome-shell-extensions" domain you can always use > them in any case. > > Anyway, I think this should be something that must be prevented from > happening when an extension is about to be approved on > extensions.gnome.org <http://extensions.gnome.org>. Am i right? > > _______________________________________________ > gnome-shell-list mailing list > gnome-shell-list@gnome.org <mailto:gnome-shell-list@gnome.org> > https://mail.gnome.org/mailman/listinfo/gnome-shell-list > >
_______________________________________________ gnome-shell-list mailing list gnome-shell-list@gnome.org https://mail.gnome.org/mailman/listinfo/gnome-shell-list
