From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Wed, 01 Jun 2011 09:58:31 +0100 Subject: [Cluster-devel] [PATCH] Add i18n infra-structure. In-Reply-To: <4DE5BFDA.2010404@redhat.com> References: <1306870631-27386-1-git-send-email-cmaiolino@redhat.com> <4DE5BFDA.2010404@redhat.com> Message-ID: <1306918711.2847.8.camel@menhir> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, On Wed, 2011-06-01 at 06:28 +0200, Fabio M. Di Nitto wrote: > On 05/31/2011 09:37 PM, Carlos Maiolino wrote: > > This patch adds some files, directories and changes in configure.ac and Makefile.am required to i18n support. > > > > The previous patch missed changes in configure.ac and Makefile.am, this is the correct one > > > > --- > > Makefile.am | 4 +- > > config.rpath | 672 ++++++++++++++++++++++++++++++++++++++++++++++++ > > Why do we need config.rpath? What does it do in this context? > > > diff --git a/configure.ac b/configure.ac > > index 3fc02d0..aa7cc64 100644 > > --- a/configure.ac > > +++ b/configure.ac > > @@ -16,6 +16,10 @@ AC_PROG_LIBTOOL > > > > AC_LANG([C]) > > > > +#i18n > > +AM_GNU_GETTEXT > > +AM_GNU_GETTEXT_VERSION([0.18]) > > + > > # Sanitize path > > > > if test "$prefix" = "NONE"; then > > @@ -262,7 +266,7 @@ CPPFLAGS="$KERNEL_CPPFLAGS -I\$(top_builddir)/make -I\$(top_srcdir)/make \ > > -I. $ENV_CPPFLAGS" > > LDFLAGS="$ENV_LDFLAGS" > > > > -AC_CONFIG_FILES([Makefile > > +AC_CONFIG_FILES([Makefile intl/Makefile po/Makefile.in > > group/Makefile > > group/libgfscontrol/Makefile > > group/gfs_control/Makefile > > One per line, in alphabetical order please. Easier to track them. > > Same applies to Makefile.am addition for SUBDIRS and EXTRA_DIST. > > Is the build order important for po/intl vs code? > > Fabio > The build order between po and code is determined by the workflow, so what should happen is that the po files are updated by string changes from the code as code changes happen. So they need to be checked in at the same time as the code changes which also acts as a way to check that the code change isn't adding strings which are difficult to translate or near duplicates of existing strings (exact duplicates being preferred) The installation phase of building should also create the .mo files and install them, based on the existing translations. There is a macro that we need to add to the spec file to pick those up correctly and last time I looked into it, it looked fairly straight forward. The other part of the process comes via transifex, and I believe that the project already has the correct perms to allow addition of translations through this system direct to git. We should wait a bit though before requesting translations as we need to get the existing strings into a better state first. Once the strings are being built on a regular basis it should be easier to see what needs doing. We already know that there are a number of strings which are not translatable for various reasons and there are those which contain \r too. Steve.