This is the mail archive of the libc-hacker@sources.redhat.com mailing list for the glibc project.
Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
"Yoshito Kawada" <KAWADA@jp.ibm.com> writes: > ( I am not sure if I understood this portion correctly. "package" means run > time application ? ) Package means the sources or binaries (.tar.gz, rpm, ...) which are installed. The message catalogs come in source form and are compiled for the appropriate target at installation time. This will not be possible for those catalogs which require special locales or conversions since they cannot be assumed to be available. > Of course, on the environment on which gencat runs, the > corresponding locale and iconv modules must be installed, but glibc > has all of them by default, doesn't it?... First, packages are targetting more than Linux. Second, not everything must be available. People are free to remove conversion modules, for instance, they don't need. > No argument is required to this option. Instead, gencat users have to set > LANG environment variable that corresponds to the charset of the message > catalog. In other words, this option allows gencat to switch between the > original gencat logic and Mr. Hanataka's logic which depends on > multibyte-wide character conversion, which in turn requires LANG > environment variable appropriately set. Well, this is a blow against every package maintainers efforts to make her package usable by many. It would require individual rules for the installation of every single catalog. You have to select the appropriate locale. Currently the installation happens most probably in a loop like CATALOGS = ja de for f in $CATALOGS; do gencat $f.cat $f.msg cp $f.cat /usr/lib/locale/$f/LC_MESSAGES done Support for a new language means adding to the CATALOGS variable. If you force people to write special rules for each catalogs all you'll achieve is that languages which require this special behavior are not supported. > As far as our gencat is concerned, they rely on LANG environment value just > the same way I said above. Therefore, makefiles of the applications have to > include the statement to set the LANG prior to gencat. Well, look around at the packages which use catgets. > Yes, that's right. The person who creates makefile must know the encodings > of each message catalog, which could be error-prone. You also must not make the mistake of believing that the package maintainers know anything about these issues. These are the same questions we took into account when creating the gettext framework. Maintainers most of the time have no clue about internationalization and if you want them to at least distribute the work contributors provide you have to make the maintainer's job easy. Very easy, like adding an entry to a variable. > All in all, I completely agree that your method is smarter. However, my > only concern is that there exists tons of message catalogs created in the > past without "$ charset= ..." naturally, and it takes tremendous effort to > insert "$ charset= " to each one of these. No, it doesn't take much of an effort. Simply run sed '1 {i\ $ charset=sjis }' over all the catalogs you want to mark with SJIS. If the name of the charset is encoded in the catalog file or path name it is even possible to automate the whole process for all charsets. > Compared with that effort, editing makefile would be smaller in > workload. This is where you are wrong. You are thinking with the mindset of a corporation programmer where there are people who's job it is to do this and who know what to do. This won't work for free software packages where you sometimes have to beg maintainers to care about internationalization enough to distribute message catalogs. If they are required to do more than keeping track of the files they won't do it (correctly). We've done extensive studies when designing the gettext model to reach this conclusion. I'm more than ever convinced it should be up to the translator to provide the information since s/he is the only one who knows the issues involved for sure. -- ---------------. ,-. 1325 Chesapeake Terrace Ulrich Drepper \ ,-------------------' \ Sunnyvale, CA 94089 USA Red Hat `--' drepper at redhat.com `------------------------
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |