bug-gnu-utils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: gettext


From: Vlada von Strasnic
Subject: Re: gettext
Date: Fri, 12 Apr 2002 12:18:14 +0200
User-agent: Mutt/1.3.21i

On Thu, Apr 11, 2002 at 09:42:29PM +0200, Bruno Haible wrote:
> Vlada von Strasnic wrote:
> 
> > When i do 
> >         export LC_ALL=cs_CZ
> >         ls --help
> >         ls -la
> > then dates are localized , but messages from ls --help are not.
> > But they should be , because all catalogs are in /usr/share/locale/...
> 
> You can see in
>     http://www2.iro.umontreal.ca/~pinard/po/registry.cgi?team=cs
> 
> that for the newest version of 'ls' (contained in the fileutils), only
> about a third of the messages have been translated.

Oh, wait . "ls" is not the only one program, that i tried. What is
worse, even if i compile the program from sources and ./configure
detects NLS , it compiles , i do "make install" and it doesn't work !!!

This is the problem. I would be satisfied if just one message from 100
was translated. But there is not even one, because NLS somehow doesn't
work. So i would like to know 
        how can i find out , how nls support is compiled into the
                program ???
        why my programs work , when i compile them just with gcc file.c 
                ( without any -l -I )
        if the program, that realizes LC_ALL=some_language , can also
                realize, that it cannot that language !!!!

> 
> Localization is not magic; it needs volunteers who do the translation
> of the messages to a particular language.
> 
> Bruno

No, no, no !!! You are completely wrong. ( Sorry that I'm saying it ). 
Because localization is kept !!! strictly !!! magic. Program just says
bindtextdomain(..)  and doesn't receive any information back : 
        - if the directory that was argument to bindtextdomain is usable
        - what catalogs are installed there
        - if the language , that is requested by LC_ALL or some other
                variable is really there ...
        - if program tries to translate some message, it doesn't really know 
                if it really get translated ... And if requested more than 
                one language , you have no way to realize into what
                language, it had been really translated !!!!!!!
This means that its kept magic.


Well, maybe you think i'm just flaming you and others who are working on
intl problems. That's not truth. I'm speaking very badly english and 
i'm sometimes very happy, when i can use localized version of program 
( that is surely not case of "ls" ) . 
        My problem is this: 
i'm currently writing some programs and i'm 99% decided not to use gettext,
because the problems, which are mentioned up. There is one more:
 Structure of catalogs is this:
        ../locale/cs/LC_MESSAGES/my_program_name.mo
        ../       de/           /..
        ../       sk/           /..
        ../                     /..
 What if my country has several dialects ??? How can i write several
catalogs for one country.

        ../locale/cs_official/LC_MESSAGES/my_program_name.mo
        ../locale/cs_morava/LC_MESSAGES/my_program_name.mo
        ../locale/cs_praha/LC_MESSAGES/my_program_name.mo

This is surely not correct way .
There is however one way, how it can be solved :

        ../locale/cs/LC_MESSAGES/my_program_name.mo
        ../locale/cs/LC_MESSAGES/my_program_name_praha.mo
        ../locale/cs/LC_MESSAGES/my_program_name_morava.mo
        ../       de/           /..

But this is just nasty workaround, because it's completely against the
main idea on which is gettext build on. So i would be glad, if there is
some other way.

--------

I would be glad, if i could use gettext, because it's a standard. 
I don't want to write just another intl package, that will be
incompatible with everything existing. So if gettext is able to solve
that 5 problems, that i mentioned up  in some clever way... and you
will let me know ... then i will be quite glad .
        If it cannot, than gettext is just another package, that should
be revised in very large scale to become usefull. However i don't want
to learn how it works inside just beacuse of trying to do it better and
not break compatibility with everything else ( this should be done, 
by someone involved ). 

Anyway i accept any notes to this.. Even, if you think, that my 
problems are so minor, and that they are of small priority..
  

Hi Suk

-- 
signed short            (mail)



reply via email to

[Prev in Thread] Current Thread [Next in Thread]