Re: [bug-gettext] gettext 0.18.2 fails to compile without optimisations

Paul Eggert writes: > On 01/16/13 01:08, Daiki Ueno wrote: >> I'm not 100% sure if this is the right fix, so Cc'ed bug-gnulib. > > This patch looks good to me. Might there be other files > with the same problem? Maybe gettext should be changed to > use gnulib-too

Re: [bug-gettext] 0.18.2: install fails, missing COPYING.LIB-*

all" step fail, or does it? Regards, -- Daiki Ueno >From c1ca62c334121dad1d50f924545a6c99eb1ada6d Mon Sep 17 00:00:00 2001 From: Daiki Ueno Date: Mon, 21 Jan 2013 11:09:24 +0900 Subject: [PATCH] Remove references to non-existing COPYING.LIB-2.*. --- gettext-runtime/intl/ChangeLog

[bug-gettext] branching plans

where all the bug fixes shall be checked in first, and merge the changes periodically to the master. And the topic branches for the features will be branched off from "maint". What do people think? Regards, -- Daiki Ueno

Re: [bug-gettext] Glade/GtkBuilder related bugs

Hi, Miguel Ángel writes: > I have sent a patch for the bug #34506 that solves the "context" > problem, but I think that is a first approach, because it looks for it > in every tag. Thanks for the patch. A comment and a revised patch are below. > I will thank any advices if I have to sign anyt

Re: [bug-gettext] Glade/GtkBuilder related bugs

Also please separate out unrelated changes, like: https://github.com/644rosen/gettext_gtkbuilder_support/commit/f766f238 I think this commit can be merged regardless of glade/gtkbuilder support. Thanks for triaging the bugs anyway! Regards, -- Daiki Ueno

Re: [bug-gettext] branching plans

e features will be branched off from "maint". > > Looks good. So there was no objection so far, I've created "maint" branch and started pushing some minor fixes onto it. Regards, -- Daiki Ueno

Re: [bug-gettext] 0.18.2: install fails, missing COPYING.LIB-*

And this should affect all platforms. Well, it does not fail on GNU/Linux (and FreeBSD). I don't have working OpenBSD guest at the moment but perhaps it depends on SHELL (I remember OpenBSD uses ksh?). If the problem is severe we could release 0.18.2.1. Regards, -- Daiki Ueno

Re: [bug-gettext] [Patch 1/1] Savannah bug #36063

'll(_DD)', so the bug should be fixed with > this patch. Thanks, pushed to maint. Regards, -- Daiki Ueno

Re: [bug-gettext] [RFC Patch] Implement \u support in xgettext for C family (C11/C++11)

tend testsuite, because I have tested it with simple > files and my current make check (with GtkBuilder support). Nice. A minor thing, it might be good to use spaces consistently in the source code. Regards, -- Daiki Ueno

Re: [bug-gettext] [RFC Patch] Implement \u support in xgettext for C family (C11/C++11)

tin1.c Suppose that latin1.c contains an ISO-8859-1 string with Unicode escapes. If 'xgettext_current_source_encoding' is set to UTF-8, ISO-8859-1 part of the string will be treated as UTF-8 and thus cause erroneous conversion. So I'd suggest to first convert the Unicode characters given by Unicode escapes into the source encoding (in x-c.c), and then let 'remember_a_message' to convert them into UTF-8. Regards, -- Daiki Ueno

Re: [bug-gettext] [RFC Patch] Implement \u support in xgettext for C family (C11/C++11)

Daiki Ueno writes: > So I'd suggest to first convert the Unicode characters given by Unicode > escapes into the source encoding (in x-c.c), and then let > 'remember_a_message' to convert them into UTF-8. Sorry, it doesn't work, since it is likely that the escape is

Re: [bug-gettext] gettext compilation error on Mac OS X 10.6.8

is a 'gnulib' related issue, has been discussed and resolved (in the > context of GNU coreutils) here: > http://bugs.gnu.org/13495 > > Perhaps it would be possible to release a new minor gettext version with this > fix? Thanks for the information. I'll make a new m

Re: [bug-gettext] [PATCH] Determine Woe32 C symbol prefix at configure time.

aint branch. You could rework it later when you find time :) Regards, Footnotes: [1] https://lists.gnu.org/archive/html/bug-gettext/2012-12/msg00071.html -- Daiki Ueno

Re: [bug-gettext] gettext compilation error on Mac OS X 10.6.8

nulib-tool: *** patch file > gnulib-local/lib/unistd.in.h.diff didn't apply cleanly > """ Thanks, fixed. I've overlooked build failure notification from Hydra on Feb 8[1] :) Regards, Footnotes: [1] http://hydra.nixos.org/build/4014724 -- Daiki Ueno

Re: [bug-gettext] autosprintf and gettext mixed up manuals

them. Footnotes: [1] http://git.savannah.gnu.org/cgit/gettext.git/tree/Admin/release-steps Regards, -- Daiki Ueno

Re: [bug-gettext] AC_CONFIG_MACRO_DIR{,S} & ACLOCAL_AMFLAGS

. Could you check the attached patch? Probably autopoint also needs similar treatment. Regards, -- Daiki Ueno >From 699a68cf65c49c85b8734460640c0014e7644758 Mon Sep 17 00:00:00 2001 From: Daiki Ueno Date: Wed, 27 Feb 2013 17:20:03 +0900 Subject: [PATCH] gettextize: extract macro directories f

Re: [bug-gettext] AC_CONFIG_MACRO_DIR{,S} & ACLOCAL_AMFLAGS

t should be addressed by a separate patch. I also wonder if grep is even necessary. Anyway, patches are welcome ;) Regards, -- Daiki Ueno

Re: [bug-gettext] Sync the code for determining PATH_SEPARATOR with the one in Autoconf

make). Thanks. Regards, -- Daiki Ueno

[bug-gettext] Python 3 format strings

8.html Regards, -- Daiki Ueno

Re: [bug-gettext] AC_CONFIG_MACRO_DIR{,S} & ACLOCAL_AMFLAGS

ed, it could be ported to 'autopoint' (since they shares a large amount of code). > Btw. I tried to test this and it seems to work - but building of gettext > from git is quite painful :( > ~> http://lists.gnu.org/archive/html/bug-gettext/2012-12/msg00058.html Right, but I don't have a good idea for this. Perhaps it might be ok to version control the contents of archive.tar. Regards, -- Daiki Ueno

Re: [bug-gettext] AC_CONFIG_MACRO_DIR{,S} & ACLOCAL_AMFLAGS

of > months ago (before Automake 1.13 was released), using ACLOCAL_AMFLAGS > was the only way to specify local m4 directory for aclocal and > autoreconf, so almost all the existing autotools based packages still > rely on it (and certainly will until they can start assuming Automake > 1.13 or later). Thank you very much for the clarification. Now the background is much clearer to me. Regards, -- Daiki Ueno

Re: [bug-gettext] New Gettext contributor

gt; * libasprintf bug fixes (two patches) > * libgettextpo bug fix (one patch) Those patches are small and I don't think they need separate remote branches. Regards, -- Daiki Ueno

Re: [bug-gettext] [Patch 2/2] Libasprintf bug fixes

a124d0cb326acd4dfa9ce3276baa26734b16 Author: Bruno Haible Date: Sun Feb 13 23:21:20 2011 +0100 Don't interfere with a program's definition of __attribute__. <http://git.savannah.gnu.org/cgit/gnulib.git/commit/?id=f6a5a124d0cb326acd4dfa9ce3276baa26734b16> Regards, -- Daiki Ueno

Re: [bug-gettext] [Patch 1/1] arglist_parser_* memory leaks

gression. Well, though it looks the code should work, how is the impact of the memory leaks? Since 'xgettext' is not a long running program (nor a library), can't we simply ignore it if it is not severe? Regards, -- Daiki Ueno

Re: [bug-gettext] New Gettext contributor

Miguel Ángel writes: > Daiki Ueno writes: >> Miguel Ángel writes: >> It seems not yet, see my private mail. > > Yes, I saw it. How couldn't i see there is no sign in the pdf? :( Maybe good to wait for the response from FSF copyright clerk, before starting actua

Re: [bug-gettext] AC_CONFIG_MACRO_DIR{,S} & ACLOCAL_AMFLAGS

Daiki Ueno writes: > Pavel Raiskup writes: > >> autom4te --language Autoconf-without-aclocal-m4 >> --trace=AC_CONFIG_MACRO_DIR configure.ac >> >> // and for the up2date autoconf (not yet released) should be used (See >> // autoconf's manual fr

Re: [bug-gettext] [Patch 2/2] Libasprintf bug fixes

ge about > it. :) Please note that some files are shared among gnulib and gettext. For maintenance, minimizing the local changes would be more important. Regards, -- Daiki Ueno

Re: [bug-gettext] [Patch 1/1] arglist_parser_* memory leaks

t wouldn't be too late, even if we fixed this after we got a practical bug report. Regards, -- Daiki Ueno

Re: [bug-gettext] [Patch 1/2] Libasprintf bug fixes

std::swap (tmp.str, this->str); > + } > +return *this; > + } > + I'm not familiar with C++, but is 'tmp' really needed here? autosprintf& operator = (autosprintf& src) { std::swap (str, src.str); return *this; } Regards, -- Daiki Ueno

Re: [bug-gettext] [Patch 1/2] Libasprintf bug fixes

on. Then, how about: autosprintf& operator = (autosprintf src) or just providing autosprintf::swap instead of the assignment operator? Sorry for grumbling, but I like simplicity. At least, "autosprintf::" prefix can be removed from your patch. Regards, -- Daiki Ueno

Re: [bug-gettext] [Patch 1/2] Libasprintf bug fixes

Miguel Ángel writes: > Daiki Ueno writes: >> autosprintf& operator = (autosprintf src) > > This imply the copy constructor when calling. Also It is not the C++ > convention and It does not optimize self assignment. But in most cases we need the copy constructor call, n

Re: [bug-gettext] AC_CONFIG_MACRO_DIR{,S} & ACLOCAL_AMFLAGS

gt;> blocker in these patches. Thanks Pavel, renamed to $autom4te and pushed. > +autoconf="autom4te --no-cache --language=Autoconf-without-aclocal-m4" > is the "--no-cache" flag really needed? It is to avoid unnecessary autom4te.cache creation in a fresh project. Regards, -- Daiki Ueno

Re: [bug-gettext] [Patch 2/2] Libasprintf bug fixes

Miguel Ángel writes: > Daiki Ueno writes: >> Please note that some files are shared among gnulib and gettext. For >> maintenance, minimizing the local changes would be more important. > > You are right, I am reverting it (with GI changed to GT) By the way, changes to

[bug-gettext] GNU gettext 0.18.2.1 released

for 0.18.2. Download at http://ftp.gnu.org/gnu/gettext/gettext-0.18.2.1.tar.gz Regards, -- Daiki Ueno pgpgjNDnCbipE.pgp Description: PGP signature

Re: [bug-gettext] [Patch 2/2] Libasprintf bug fixes

Miguel Ángel Arruga Vivas writes: > It is not the same patch as gnulib, because I preserved GCC 2.5 and > 2.6 compatibility. v*printf changes has been removed. Looks good to me. Regards, -- Daiki Ueno

[bug-gettext] Mac OS X: dcigettext and LC_GLOBAL_LOCALE

fferent global locale settings, the search hits and returns the translation for a locale previously set with setlocale(). I'm attaching a patch to fix this. Although there are some whitespace changes, it merely adds a guard: if (uselocale (NULL) != LC_GLOBAL_LOCALE) to the cache lookup. Reg

Re: [bug-gettext] [Patch 2/2] Libasprintf bug fixes

t indicate it is expanded to a GCC attribute, though it is not a blocker). Regards, -- Daiki Ueno

[bug-gettext] [PATCH] Generate autopoint archive when bootstrapping

y comments would be appreciated. Regards, -- Daiki Ueno >From 49cd3a513cc1707c2ede81bf55ea1ce43cd3ea84 Mon Sep 17 00:00:00 2001 From: Daiki Ueno Date: Wed, 6 Mar 2013 18:46:15 +0900 Subject: [PATCH] Generate archive.dir.tar when bootstrapping --- ChangeLog

Re: [bug-gettext] Mac OS X: dcigettext and LC_GLOBAL_LOCALE

Daiki Ueno writes: > See <https://savannah.gnu.org/bugs/?38162>. > So, if dcigettext is called twice on a same string with different global > locale settings, the search hits and returns the translation for a > locale previously set with setlocale(). > it merely a

Re: [bug-gettext] [PATCH] Generate autopoint archive when bootstrapping

tar, until running "make install" Regards, -- Daiki Ueno

Re: [bug-gettext] [feature request] msggrep --reference

dcard pattern. Doesn't this help? You could do something like: msggrep -N ../content/\* input.po | msggrep --msgid -F -e 'Please specify' Regards, -- Daiki Ueno

Re: [bug-gettext] msguniq fails on a duplicate empty msgid

d-catalog.c:358: if (this->allow_duplicates && msgid[0] != '\0') /* Doesn't matter if this message ID has been seen before. */ mp = NULL; (As you know, the empty msgid is kind of reserved for PO file headers.) Regards, -- Daiki Ueno

Re: [bug-gettext] [PATCH] Describe the header entry in the PO format section

Andreas Stricker writes: > +2013-02-15 Andreas Stricker > + > + * msgfmt.texi (PO Format): A note about the header entry > + Thanks. Applied with a slight modification. Regards, -- Daiki Ueno

[bug-gettext] Glade msgctxt patch

o it doesn't support GtkBuilder-style context attribute yet, but I'd like to get things done step by step.) Anyway, if there is no serious issue, I'll push it to git. Regards, -- Daiki Ueno >From 4d20a0e573e1bbf802b84b8a33995cdd1d4ef737 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?

Re: [bug-gettext] Glade msgctxt patch

atkproperty test case is not related to the context support, right? Also perhaps it might be good to add a wrong element to the xgettext-glade-5 to test the failure case. I'm looking at: https://github.com/644rosen/gettext_gtkbuilder_support/commit/91dfcd209b153f61c02a0c8db188c8cb9cf8f7c1 Regards, -- Daiki Ueno

Re: [bug-gettext] msggrep -f treats empty lines as .*

Raphaël writes: > When using msggrep -f file.sed in order to use file.sed as the storage > for a list a regexp (1 per line), > it ignores lines beginning with # but treat empty line as a catch-all (.*) I think this is normal, as grep -f behaves like that. For #, isn't it simply because there is

Re: [bug-gettext] Glade msgctxt patch

to the ChangeLog entry). Could you push the test cases to maint? Regards, -- Daiki Ueno

[bug-gettext] GtkBuilder support

than ~100 lines. By the way, by grepping the GTK+ source, it seems and elements are also translatable. Regards, -- Daiki Ueno

Re: [bug-gettext] GtkBuilder support

ot; are called 'regular > translation attributes'[7] and also 'usual "translatable" and "context" > attributes'[8]. Yes, it is actually what intltool does (and I think it's a good idea). Regards, -- Daiki Ueno

Re: [bug-gettext] gettext-0.18.2.tar.gz

es, such as 0.18.1.1? Also could you try the gnulib testbed? $ git clone git://git.savannah.gnu.org/gnulib.git $ ./gnulib/gnulib-tool --create-testdir --dir=test-pipe-filter-ii pipe-filter-ii $ cd test-pipe-filter-ii $ ./configure $ make Regards, -- Daiki Ueno

Re: [bug-gettext] [Q] How do I remove compilation errors on MinGW?

[1] https://lists.gnu.org/archive/html/bug-gnulib/2012-12/msg0.html Regards, -- Daiki Ueno

Re: [bug-gettext] [Q] How do I remove compilation errors on MinGW?

ugh libiconv's iconv.h and wchar.h. Which is causing multiple definition. I'll try to find a better solution, but a workaround is to use win-iconv (whose iconv.h does not include wchar.h) instead of libiconv: https://code.google.com/p/win-iconv/ Regards, -- Daiki Ueno

Re: [bug-gettext] [Q] How do I remove compilation errors on MinGW?

bugging, it turned out that the root cause is towlower/towupper declarations in mingw's . I've posted a patch to bug-gnulib to work around this: <http://lists.gnu.org/archive/html/bug-gnulib/2013-03/msg00095.html> Or perhaps you could use mingw-w64 instead of mingw: <http://mingw

Re: [bug-gettext] Lua gettext extractor

ory (and releases)? Have you already asked the author if he is willing to upstream this? The extractor looks non-trivial in size and we would need the FSF copyright assignment. Regards, -- Daiki Ueno

Re: [bug-gettext] gettext-lua

hangul/compare/master...gnome-common Probably we should add some git-specific notes in HACKING. > Daiki, can you please review it and tell me if there's anything else > that needs to be done to get this merged upstream? Sure. Regards, -- Daiki Ueno

Re: [bug-gettext] gettext-lua

Daiki Ueno writes: >> Daiki, can you please review it and tell me if there's anything else >> that needs to be done to get this merged upstream? > > Sure. Anyway, I've checked x-lua.c and it looks mostly good to me, except coding styles and a minor issue in phase2

Re: [bug-gettext] gettext-lua

the right gettext extension needed at run time? https://github.com/LubomirR/luagettext If so, it might be good to mention it somewhere in docs. Regards, Footnotes: [1] https://www.gnu.org/prep/standards/standards.html#Comments -- Daiki Ueno

Re: [bug-gettext] Using gettext in ZNC

rce file: > - > #include "gettext.h" > #include "locale.h" > setlocale (LC_ALL, "de_DE"); > textdomain ("ClientCommand"); > bindtextdomain ("ClientCommand", "/home/znctest/locale"); > cout << gettext("hello, world!") << "\n"; > - Regards, -- Daiki Ueno

Re: [bug-gettext] Using gettext in ZNC

EC) = 3 open("/lib64/libm.so.6", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libgcc_s.so.1", O_RDONLY|O_CLOEXEC) = 3 open("/lib64/libc.so.6", O_RDONLY|O_CLOEXEC) = 3 open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3 hello, world! +++ exited with 0 +++ Regards, -- Daiki Ueno

Re: [bug-gettext] JavaScript support

(For bug-gettext, the original article seems to be still under moderation, possibly because of Unicode characters in the patch. Quoting the text part) Daiki Ueno writes: > Now that the copyright situation seems clear, I'm checking the > JavaScript support. The attached is a revised

[bug-gettext] [PATCH] Support explicit string concatenation with '+' in Python.

--- gettext-tools/src/x-python.c | 76 --- gettext-tools/tests/xgettext-python-1 | 8 2 files changed, 70 insertions(+), 14 deletions(-) diff --git a/gettext-tools/src/x-python.c b/gettext-tools/src/x-python.c index aa6a7d6..cdca255 100644 --- a/get

[bug-gettext] [PATCH] Convert line endings when scanning Python source code

d CRLF) to LF. >From 346699bfec77187eea1734d338855015a94824b6 Mon Sep 17 00:00:00 2001 From: Daiki Ueno Date: Tue, 16 Apr 2013 15:17:14 +0900 Subject: [PATCH] Convert line endings when scanning Python source code --- gettext-tools/src/x-python.c | 16 +++- 1 file changed, 15 i

Re: [bug-gettext] [PATCH] Convert line endings when scanning Python source code

Daiki Ueno writes: > From 346699bfec77187eea1734d338855015a94824b6 Mon Sep 17 00:00:00 2001 > From: Daiki Ueno > Date: Tue, 16 Apr 2013 15:17:14 +0900 > Subject: [PATCH] Convert line endings when scanning Python source code Sorry, the attached patch should be be

Re: [bug-gettext] JavaScript support

gnu.org/cgit/gettext.git/commit/?h=maint&id=fe8db3b5b44cd23385e3dfccf54249b742d8d994 with some more changes: * added format-javascript-* tests * added lang-javascript test * rewrote format-javascript.c to accept only C-style format strings * remove unnecessary open_pbb handling from x-javascript.c Regards, -- Daiki Ueno

[bug-gettext] [PATCH] Make header checking more reliable.

See . Currently, msgfmt --check-header simply scans the message header with c_strstr. This causes false positive warnings. For example, Language-Team: Foo Language Team results in: warning: header field `Language' should start at beginning of line b

Re: [bug-gettext] msgfilter: Rules-quot implicity depends on GNU Sed.

Thanks for the suggestion. I'll do that. Regards, -- Daiki Ueno

[bug-gettext] [PATCH v3] Support Python brace format.

this soon, if no one objects. >From f52e0d209da7b5ae5ee99b672654e4d8ca60b4f1 Mon Sep 17 00:00:00 2001 From: Daiki Ueno Date: Mon, 22 Apr 2013 20:01:12 +0900 Subject: [PATCH] Support Python brace format. --- gettext-tools/src/FILES | 1 + gettext-tools/src/Makefile.am

Re: [bug-gettext] [PATCH] Adding a git .mailmap file to gettext

Stefan Beller writes: > I am sending a patch for gnu gettext, which adds a > .mailmap file. This file is read by git to map commits > by the same person in the shortlog, where their name > and/or email address was spelled differently. Thanks, applied. Regards, -- Daiki Ueno

Re: [bug-gettext] reversible recode-sr-latin?

int *in_verb, int *out_verb, int reverse) > +{ > + if (reverse) > +to_cyrillic (in, in_len, out, out_len, in_verb, out_verb); > + else > +to_latin (in, in_len, out, out_len, in_verb, out_verb); > } Why not add a separate function like latin_to_serbian, instead of adding REVERSE flag? Also, bool type can be used for flags. Regards, -- Daiki Ueno

[bug-gettext] [PATCH] Obsolete gt_CHECK_DECL in favor of AC_CHECK_DECLS.

-runtime/m4/ChangeLog +++ b/gettext-runtime/m4/ChangeLog @@ -1,3 +1,12 @@ +2013-04-23 Daiki Ueno + + Obsolete gt_CHECK_DECL in favor of AC_CHECK_DECLS. + Now that macros installed by 'gettextize' require Autoconf 2.60, + gt_CHECK_DECL can be safely replaced with AC_C

[bug-gettext] [PATCH] Don't assume that aclocal accepts configure.in.

(+), 4 deletions(-) diff --git a/gettext-tools/examples/ChangeLog b/gettext-tools/examples/ChangeLog index b3461f8..e3cbdc2 100644 --- a/gettext-tools/examples/ChangeLog +++ b/gettext-tools/examples/ChangeLog @@ -1,3 +1,7 @@ +2013-04-23 Daiki Ueno + + * po/xsmallpot.sh: Don't assume

Re: [bug-gettext] "make all" failure after bootstrap

chive in git: http://lists.gnu.org/archive/html/bug-gettext/2013-03/msg00044.html However, I'll probably withdraw the idea as it seems too much. Instead, I plan to put archive.dir.tar.gz on our ftp server upon release and fetch it when bootstrapping. Regards, -- Daiki Ueno

Re: [bug-gettext] [PATCH 4/4] xg-js: fix end-of string miss bug due to backslashes

scapeSequence is the CV of the EscapeSequence. * The CV of CharacterEscapeSequence :: NonEscapeCharacter is the CV of the NonEscapeCharacter. where CV stands for "character value". That means, "\xxx" should be treated as "xxx", while the current implementation treats it as "\\xxx". Regards, -- Daiki Ueno

[bug-gettext] [PATCH] Refactor Autoconf trace in autopoint

I noticed that autopoint --force copies unnecessary 'intl' directory if there are extra whitespaces before AM_GNU_GETTEXT([external]). This patch fixes that and generalize the Autoconf trace stuff in autopoint.in. --- gettext-tools/misc/autopoint.in | 59 +++--

Re: [bug-gettext] "make all" failure after bootstrap

olve the current > bootstrapping problems, which is the real hurdle. Further enhancements > can be done later, if needed. I did this and put archive.dir.tar.gz on alpha.gnu.org (since it is for Alpha testers). Please let me know if there is any problem. Regards, -- Daiki Ueno

Re: [bug-gettext] msginit on OS X 10.8 displays sed "unterminated substitute pattern"

.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/Limitations-of-Usual-Tools.html#sed> I'm attaching a patch, but I guess there is a smarter solution for this. Comments would be appreciated. Regards, -- Daiki Ueno >From 97543ced8b32cae0e757baf134a0f2b0367722a9 Mon Se

Re: [bug-gettext] msginit on OS X 10.8 displays sed "unterminated substitute pattern"

Ineiev writes: >> s/\ >> // > > Won't s/\n// work? Right, it seems to work and probably portable (according to the Autoconf manual I quoted and SUSv3). I've pushed a fix it in that way. Thanks! Regards, -- Daiki Ueno >From ae7b0f726f5843396431173e65937b4523

Re: [bug-gettext] [PATCH] intl: fix build targetting 10.6 with newer SDK's

endif Probably it can be safely #undef'ed without #ifdef. Footnotes: [1] http://gcc.gnu.org/onlinedocs/gcc-4.8.0/cpp/If.html#If Regards, -- Daiki Ueno

Re: [bug-gettext] XML Support

in msg* tools might be more useful. For example, if we had a special flag to indicate that msgid contains XML fragment: #, xml-markup msgid "foo" msgstr "bar" msgfmt -c could report error, as the para tag in msgstr is not balanced. Regards, -- Daiki Ueno

Re: [bug-gettext] [PATCH 4/4] xg-js: fix end-of string miss bug due to backslashes

Daiki Ueno writes: > Thanks for looking into this. However, I doubt that backslash_counter > is even needed for JavaScript parser. The original code in the Python > parser has a check like this: > > if (c == quote_char && (interpret_ansic || (*backslash_counter &

Re: [bug-gettext] win32 gettext-0.14.4 context argument

to the NEWS: <http://git.savannah.gnu.org/cgit/gettext.git/tree/NEWS#n162> Java msgctxt support has been added since 0.17. Regards, -- Daiki Ueno

Re: [bug-gettext] [Q] How do I remove compilation errors on MinGW?

Sorry for the late response. > The build failed even with MinGW-w64. I've just tried self-compile with mingw-w32-bin_i686-mingw_20111219 and confirmed the issue. It seems that AC_CHECK_FUNCS cannot detect snprintf because of a link error if the stdio.h is not included: $ cat > test-snprintf.c <

Re: [bug-gettext] msgattrib --previous

rer solution. > > What do people think? Sorry for the late response. Sounds plausible and the patch looks good. Can I have the ChangeLog entry? Regards, -- Daiki Ueno

Re: [bug-gettext] msgattrib --previous

Ineiev writes: > On 05/20/2013 10:52 AM, Daiki Ueno wrote: >> Sounds plausible and the patch looks good. >> Can I have the ChangeLog entry? > > Will the attached do? Thanks, applied (as a trivial change). For further contributions, probably we will need to ask you for the

Re: [bug-gettext] Generalized Gettext, take two

ars I don't recall > there being a bug reported on the translation system itself, or any > particular increase in bugs in translation caused by the system. So, has the translation system already been practically used? Regards, -- Daiki Ueno

Re: [bug-gettext] [PATCH] build: enable parallel tests harness from Automake

ake versions, it caused some errors with conflicting temp file names. So, I'm going to install LOG_COMPILER change only at the moment (patch attached). Is it fine with you? Regards, -- Daiki Ueno >From e26d7fde591a53863879480a250e9050a9d3d720 Mon Sep 17 00:00:00 2001 From: Stefano Lattarini Date:

[bug-gettext] [PATCH] Support for Vala

attrib_SOURCES = msgattrib.c else diff --git a/gettext-tools/src/x-vala.c b/gettext-tools/src/x-vala.c new file mode 100644 index 000..5cbf021 --- /dev/null +++ b/gettext-tools/src/x-vala.c @@ -0,0 +1,1310 @@ +/* xgettext Vala backend. + Copyright (C) 2013 Free Software Foundation, Inc. + +

Re: [bug-gettext] [PATCH] build: enable parallel tests harness from Automake

Hmm, that's unfortunate indeed. Okay, let's remove the filename conflicts either by adding a test script wrapper or sanitizing all the tests. Regards, -- Daiki Ueno

[bug-gettext] [PATCH] Add a test wrapper to avoid temp file name collision.

Daiki Ueno writes: > Hmm, that's unfortunate indeed. Okay, let's remove the filename > conflicts either by adding a test script wrapper or sanitizing all the > tests. Here is a patch in the former approach (might be a bit hacky). Regards, -

Re: [bug-gettext] [PATCH] Add a test wrapper to avoid temp file name collision.

csharp-1, msgunfmt-java-1, msgunfmt-tcl-1 ./prog -> lang-c, lang-c++ de -> format-c-3, format-c-4 de/LC_MESSAGES -> format-c-3, format-c-4 de.po.tmp -> format-c-3, format-c-4 de.po -> format-c-3, format-c-4 de.po.un -> format-c-3, format-c-4 Regards, -- Daiki Ueno

Re: [bug-gettext] [PATCH] gettext-runtime: use @SHELL@ for the SHELL variable definition

utoconf manual: <http://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.69/html_node/The-Make-Macro-SHELL.html#The-Make-Macro-SHELL> So I've pushed the patch. Thanks. Regards, -- Daiki Ueno

Re: [bug-gettext] [PATCH] Add a --disable-tools option

cd gettext-runtime ./configure make make install Isn't it sufficient for your use-case? I think it is simple enough as --disable-tools configure option. Regards, -- Daiki Ueno

Re: [bug-gettext] [PATCH] Add a test wrapper to avoid temp file name collision.

Daiki Ueno writes: > On the other hand, by hooking strace to each test, it turned out that > the file name collisions are only 34 (listed below). > > So maybe good to fix the tests directly. I did this and pushed the 'parallel-tests' patch on top of it. I've confirm

Re: [bug-gettext] [PATCH] Add a test wrapper to avoid temp file name collision.

2013 -0700 regex: adapt to locking regime instead of depending on pthread Regards, -- Daiki Ueno

Re: [bug-gettext] [PATCH] Add a test wrapper to avoid temp file name collision.

2.0.9) * git master (guile (GNU Guile) 2.1.0.18-510ca) So I suspect it was a bug in guile fixed in 2.0.5 to 2.0.9. Regards, -- Daiki Ueno

[bug-gettext] plans for a new release

e variable in gettext-runtime/po/Makefile.in.in <https://lists.gnu.org/archive/html/bug-gettext/2013-04/msg00028.html> * git submodule migration Although this won't affect the installed system, it will simplify the release procedure a bit. What do people think? Regards, -- Daiki Ueno

Re: [bug-gettext] plans for a new release

7;bootstrap'. > - Cosmetic issue: in the heading comments, "1.13" is not reported > among the supported Automake versions. > > Finally, it would also be nice to update all the Gettext code to use > $(MKDIR_P) instead of the deprecated $(mkdir_p) ;-) Sure, thanks for reminding. Regards, -- Daiki Ueno

Re: [bug-gettext] plans for a new release

). I've tested with > Automake 1.11.1, 1.12.6, 1.13.3, noticing no issue. Thanks. I was also wondering what was the problem that the script tries to solve, but don't see any issue so far. Pushed. Regards, -- Daiki Ueno

Re: [bug-gettext] Uses of obsolete $(mkdir_p) in gettext codebase.

glib gnulib-local/modules/libxml However, I've left gettext-runtime/intl/Makefile.in and gettext-runtime/po/Makefile.in.in untouched, since 'gettextize' script supports Automake 1.8 or later and I'm not sure if we can safely bump the required version. Any suggestions? Regards, -- Daiki Ueno

Re: [bug-gettext] Uses of obsolete $(mkdir_p) in gettext codebase.

I think that is not an unfair requirement today; automake > versions older than 1.11 are *really* outdated IMO. Thanks; mentioned that in NEWS. Regards, -- Daiki Ueno

  1   2   3   4   5   6   >