{"id":3141,"date":"2017-11-20T17:15:44","date_gmt":"2017-11-20T15:15:44","guid":{"rendered":"https:\/\/www.systemcodegeeks.com\/?p=3141"},"modified":"2017-11-20T11:37:02","modified_gmt":"2017-11-20T09:37:02","slug":"making-native-language-support-nls-gettext-optional","status":"publish","type":"post","link":"https:\/\/www.systemcodegeeks.com\/linux\/making-native-language-support-nls-gettext-optional\/","title":{"rendered":"Making Native Language Support (NLS) and gettext Optional"},"content":{"rendered":"

I’ve decided to write this blog post after noticing\u00a0how many <\/i>people were asking me to make gettext <\/code>optional when building fswatch<\/code>. At the beginning I actually thought it was<\/i> optional. And I never dug any deeper into the matter because, apparently, everybody experiencing this problem was building fswatch <\/code>from the repository sources instead of building it from a release tar-ball. I would typically answer to build the release tar-ball instead and I would hear no more complaints.<\/p>\n

Making gettext <\/code>optional is easy, and should be a best practice when writing a piece of software. However, I’ve seen so many questions in the Internet about this topic that I’ve decided to write a blog post where I would outline the reasons why you should do it and\u00a0how<\/i> you should do it using the GNU Autotools.<\/p>\n

So, What’s the Issue With Building From Repository Sources?<\/h3>\n

Actually there’s no issue. But probably many people asking that question don’t know how the Autotools work. Autoconf is a tool whose goal is producing scripts (the ubiquitous
\nconfigure <\/code>script) that configure the source code before building it to adapt it to the characteristics of the current system. In a typical flow the user does nothing but running configure<\/code>. The script will run and will test for the presence of all the features requested by the author. The presence of a feature, or its lack thereof, can then be used to parametrise Makefiles<\/code>, or more generally, be used to conditionally drive the execution of other tests or scripts.<\/p>\n

The Autotools are\u00a0not<\/i> required by end users. The scripts generated by the Autotools are\u00a0fully<\/i> independent from them. These script are then bundled with the sources (in a
\ndistribution<\/i>) which is often called a\u00a0release tar-ball<\/i>.<\/p>\n

As you can see, the goal of the Autotools is making\u00a0users’<\/i> life simple, not\u00a0maintainers’<\/i>. In fact, maintainers\u00a0need<\/i> to have the Autotools components they use in order to generate a distribution. These are the sources you typically find in a package repository such as fswatch<\/code>.\u00a0That’s<\/i> why you don’t find any configure <\/code>script in the source repository: it’s created when a release is created and a distribution is packaged.<\/p>\n

Perhaps not surprisingly,\u00a0GNU gettext<\/i> is one of the components software authors may use conditionally. configure <\/code>would then check the build environment to detect the availability of all the required gettext <\/code>components and enable\u00a0Native Language Support<\/i> (NLS) if all checks succeed.<\/p>\n

What’s Special About Gettext?<\/h3>\n

This Autotools overview doesn’t explain, though, what’s the issue about gettext<\/code>. If it’s just one of the many configuration checks performed by configure<\/code>, what’s the relationship with the Autotools and the repository sources? The answer is that gettext\u00a0<\/code>provides a tight integration with the Autotools, in the form of ready to use Autoconf and Automake macros to support the gettext operations during a normal workflow, such as:<\/p>\n