All the docs for the maintainer side of i18n I found use intltool and
glib-gettext, yet I see bugzilla bugs open to use upstream gettext /
autopoint.
Do you have a description of The Right Way(tm)?
Cheers,
Patrick
___
desktop-devel-list mailing list
ng an unlikely related
> >> > file type to x-glade.c to parse also GSettings) and the second needs
> >> > GtkBuilder extraction and
>
> Sorry for the intromision in the conversation,
Don't worry, any comment is welcome. This is the foundation of a public
mailing l
On Tue, 2013-03-05 at 20:15 +0100, Miguel Ángel Arruga Vivas wrote:
> OTOH, and in my very humble opinion, I think that generic XML parsing in
> intltool is not the right way. Internationalize an xml file must not
> modify its structure:
> 1- There is an standard attribute 'xml:lang' that could be
Shaun McCance wrote:
> On Tue, 2013-03-05 at 20:15 +0100, Miguel Ángel Arruga Vivas wrote:
> Luckily, there's a W3C standard to do exactly this:
>
> http://www.w3.org/TR/its/
>
> And version 2.0 is due to be a recommendation later this year:
>
> http://www.w3.org/TR/its20/
>
> And we already
Hi there,
I had to dig into the differences between pure gettext and intltool
based packages recently and wondered why we still have glib-gettext in
the picture in most modules: isn't gettext (and optionally intltool)
enough these days?
I checked out gnome-hello and rep
On Fri, 2016-04-22 at 08:49 +0100, Patrick Welche wrote:
> All the docs for the maintainer side of i18n I found use intltool and
> glib-gettext, yet I see bugzilla bugs open to use upstream gettext /
> autopoint.
>
> Do you have a description of The Right Way(tm)?
Upstream gettex
On Fri, 2016-04-22 at 09:54 +0100, Philip Withnall wrote:
> Upstream gettext and autopoint are the recommended tools to use,
> although you will need the latest versions of them in order to get
> support for all the things which intltool supports (namely, AppData,
> support for which
On Fri, Apr 22, 2016 at 08:39:33AM -0500, Michael Catanzaro wrote:
> We really need an intltool -> pure gettext transition guide, if anyone
> feels up for taking that on, because it's not at all clear how this is
> supposed to work.
gettext is well documented. For maintainers:
h
On 04/22/2016 10:08 AM, Sébastien Wilmet wrote:
> On Fri, Apr 22, 2016 at 08:39:33AM -0500, Michael Catanzaro wrote:
>> > We really need an intltool -> pure gettext transition guide, if anyone
>> > feels up for taking that on, because it's not at all clear how
On Fri, Apr 22, 2016 at 6:39 AM Michael Catanzaro
wrote:
> On Fri, 2016-04-22 at 09:54 +0100, Philip Withnall wrote:
> > Upstream gettext and autopoint are the recommended tools to use,
> > although you will need the latest versions of them in order to get
> > support for
On Sun, Apr 24, 2016 at 9:05 PM wrote:
> On Fri, Apr 22, 2016 at 6:39 AM Michael Catanzaro
> wrote:
>
>> On Fri, 2016-04-22 at 09:54 +0100, Philip Withnall wrote:
>> > Upstream gettext and autopoint are the recommended tools to use,
>> > although you will ne
On Mon, May 16, 2016 at 12:36 AM, wrote:
>
>
> I've done some work on this; I rewrote the wiki page titled "Localize using
> Gettext and Intltool" [1] so that it doesn't mention intltool anymore. Since
> it's a pretty drastic revision, I put it in a past
On Mon, May 16, 2016 at 4:08 AM Matthias Clasen
wrote:
> On Mon, May 16, 2016 at 12:36 AM, wrote:
>
> >
> >
> > I've done some work on this; I rewrote the wiki page titled "Localize
> using
> > Gettext and Intltool" [1] so that it doesn'
On Mon, May 16, 2016 at 10:52 PM wrote:
> On Mon, May 16, 2016 at 4:08 AM Matthias Clasen
> wrote:
>
>> On Mon, May 16, 2016 at 12:36 AM, wrote:
>>
>> >
>> >
>> > I've done some work on this; I rewrote the wiki page titled "Localize
philip.chime...@gmail.com writes:
> After trying it out, it's very unfortunate that msgfmt doesn't have an
> argument allowing you to specify a custom ITS rule; it only detects
> ones that have been installed into the Gettext data directories.
The xgettext's --its option
On Tue, May 17, 2016 at 2:36 AM Daiki Ueno wrote:
> philip.chime...@gmail.com writes:
>
> > After trying it out, it's very unfortunate that msgfmt doesn't have an
> > argument allowing you to specify a custom ITS rule; it only detects
> > ones that have be
y a custom ITS rule; it only detects
>> > ones that have been installed into the Gettext data directories.
>>
>> The xgettext's --its option was originally added for testing purpose (to
>> check if a given ITS file works as expected). The suggested way to
>> spe
Hi,
On 22 April 2016 at 08:49, Patrick Welche wrote:
> All the docs for the maintainer side of i18n I found use intltool and
> glib-gettext, yet I see bugzilla bugs open to use upstream gettext /
> autopoint.
Sorry for reopen an old thread; I've been submitting some patches and
Surprise:
Given a desktop file of the form:
[Desktop Entry]
_Name=Dasher
_GenericName=Predictive text entry
_Comment=Enter text without a keyboard
Exec=dasher
...
intltool correctly generates translation, whereas
/usr/pkg/bin/msgfmt --desktop --template dasher.desktop.in -d ../../po -o
dashe
ile.in POTFILES
$ ls ../../po/cs.gmo
../../po/cs.gmo
Problem is, the Makefile.in.in comes from gettext 19.8.1 so fiddling to
use objdir is "interesting".
Non-source tree builds impossible?
Cheers,
Patrick
___
desktop-devel-list maili
On Fri, Aug 19, 2016 at 06:10:02PM +0100, Patrick Welche wrote:
> Problem is, the Makefile.in.in comes from gettext 19.8.1 so fiddling to
> use objdir is "interesting".
s/objdir/builddir/
___
desktop-devel-list mailing list
desktop-deve
sgfmt -c --statistics
> --verbose -o cs.gmo cs.po
> 250 translated messages.
> $ ls
> Makefile Makefile.in POTFILES
> $ ls ../../po/cs.gmo
> ../../po/cs.gmo
>
> Problem is, the Makefile.in.in comes from gettext 19.8.1 so fiddling to
> use objdir is "interesting"
On Fri, Aug 19, 2016 at 4:54 PM Patrick Welche wrote:
> Maybe "remove underscores from .desktop files" could be added to the
>
> "Add rules for merging translations back into non-source files"
>
> of the useful https://wiki.gnome.org/MigratingFromIntltoolToGettext
> page?
>
Done. For next time
Hi Loïc,
Am Mittwoch, den 27.02.2008, 15:32 +0100 schrieb Loïc Minier:
> I checked out gnome-hello and replaced AM_GLIB_GNU_GETTEXT with:
> AM_GNU_GETTEXT([external])
> AM_GNU_GETTEXT_VERSION(0.14.5)
> and i18n worked seemingly as well as before.
I think reading the m4 code for the macr
Il giorno dom, 02/03/2008 alle 00.45 +0100, Sven Herzberg ha scritto:
> Hi Loïc,
>
> PS: Can you tell me about the differences between gettextize and
> autopoint (the manpages don't tell any) and why you want to move to
> autopoint (this is also likely to increase feedback).
autopoint seems to b
t even know if it is
finding the .mo file or not.
What am I doing wrong? I would appreciate any pointers.
Thanks,
Djihed
#include
#include
#include
#define _(String) gettext (String)
#define gettext_noop(String) String
#define N_(String) gettext_noop (String)
#define GETTEXT_PACKAGE "t
Le dimanche 22 avril 2007 à 02:18 +0100, Djihed Afifi a écrit :
> Hi,
Hi Djihed,
> We're still having a few problems to agree on a plural forms in Arabic,
> and I am trying to put together a test suit to test a number of plural
> forms. The code that I put together to do this is below.
>
> My un
Coming here for wider input from gnome bugzilla Bug #606977 (and now
I'm rethinking the much older Bug #500137), which seems to center on
the line in glib-2.0.pc.in:
Libs: -L${libdir} -lglib-2.0 @INTLLIBS@
The @INTLLIBS@ AC/AM variable is a standard one set by the gettext
autoconf chunk
Hello,
Sébastien Wilmet writes:
>> I don't think gettext's XML support will grow to the point where it can
>> handle complex documentation, but this is probably the way forward for
>> simple XML data files.
I plan to include it in the next release of gettext (may
On Thu, Oct 08, 2015 at 06:51:59PM +0900, Daiki Ueno wrote:
> > To mark XML attributes as translatable, a common thing to do is to
> > prefix them with an underscore. Intltool supports that, but not gettext
> > AFAIK. If the ITS branch supports that, it would cover lots o
Hi;
On 9 October 2015 at 11:11, Sébastien Wilmet wrote:
> On Thu, Oct 08, 2015 at 06:51:59PM +0900, Daiki Ueno wrote:
>> > To mark XML attributes as translatable, a common thing to do is to
>> > prefix them with an underscore. Intltool supports that, but not gettext
>>
On Fri, Oct 09, 2015 at 11:41:59AM +0100, Emmanuele Bassi wrote:
> No, not really. It's easier to see if a string is translatable if
> there is an attribute called "translate" or "translatable".
There is a difference between:
String to translate
And:
For the latter, it is convenient to prefix a
On Fri, 2015-10-09 at 13:16 +0200, Sébastien Wilmet wrote:
> On Fri, Oct 09, 2015 at 11:41:59AM +0100, Emmanuele Bassi wrote:
> > No, not really. It's easier to see if a string is translatable if
> > there is an attribute called "translate" or "translatable".
>
> There is a difference between:
> S
On Fri, Oct 09, 2015 at 09:58:34AM -0400, Shaun McCance wrote:
> On Fri, 2015-10-09 at 13:16 +0200, Sébastien Wilmet wrote:
> > There is a difference between:
> > String to translate
> >
> > And:
> >
>
> Jumping in at a random spot with a few random points:
> 3) You can only do local override
gt;
> The @INTLLIBS@ AC/AM variable is a standard one set by the gettext
> autoconf chunks. It may be blank, or contain -lintl, or whatever else
> was determined to be needed (or explicitly passed by user per normal
> autoconf methods) to link against the gettext library (libintl) at the
Hi,
On Wed, Jun 24, 2015 at 02:17:52PM +0100, Emmanuele Bassi wrote:
> On 24 June 2015 at 14:13, Michael Catanzaro wrote:
> > On Wed, 2015-06-24 at 08:56 +0100, Emmanuele Bassi wrote:
> >> I do hope that, if you're using glib-gettext or intltool, you spend a
> >&g
> > I do hope that, if you're using glib-gettext or intltool, you
> > > > spend a
> > > > little bit of time to port to upstream gettext instead.
> > >
> > > Has anyone written a guide on how to do this?
> >
> > It's the
On Fri, Oct 2, 2015 at 10:55 AM, Sébastien Wilmet wrote:
> I've tried to not add the generated *.pot files to Git, because
> generated files should not be added to the version control system.
For what it's worth, I break that rule for .pot files in my own projects,
because adding them to Git ma
On Sat, Oct 3, 2015 at 4:40 AM, Philip Chimento
wrote:
> For what it's worth, I break that rule for .pot files in my own projects,
> because adding them to Git makes it easier for people who aren't comfortable
> with the command line to contribute translations.
Are you updating the pot file every
ave XML files of translated
> strings for use in XSLT. It's a home-brewed XSLT gettext system. Here's
> the Makefile.am that manages the POT file:
>
> https://git.gnome.org/browse/yelp-xsl/tree/xslt/common/domains/Makefile
> .am
>
> Here's the POT file in git:
>
On Sat, Oct 3, 2015 at 12:49 AM, Alexandre Franke <
alexandre.fra...@gmail.com> wrote:
> On Sat, Oct 3, 2015 at 4:40 AM, Philip Chimento
> wrote:
> > For what it's worth, I break that rule for .pot files in my own projects,
> > because adding them to Git makes it easier for people who aren't
> co
41 matches
Mail list logo
