bug-gettext
[Top][All Lists]
Advanced

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

Re: [bug-gettext] Gender-aware translations


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: [bug-gettext] Gender-aware translations
Date: Tue, 04 Jun 2013 08:29:48 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130518 Icedove/17.0.5

On 04.06.2013 03:40, Amir Eldor wrote:
> On Sun, May 19, 2013 at 3:07 PM, Vladimir 'φ-coder/phcoder' Serbinenko
> <address@hidden <mailto:address@hidden>> wrote:
> 
>     On 19.05.2013 13:27, Chusslove Illich wrote:
> 
>     >> [: Amir Eldor :]
>     >> Is gender-aware translations feature for gettext planned or is there
>     >> anyone working on it? Will it be hard or take a long to implement
>     if I
>     >> decide to take such a task?
>     >
>     > Gender-aware feature could mean various things, so the first task
>     would be
>     > to define what it is exactly, which I'm not aware of anyone doing
>     right now.
>     >
>     > On the other hand, some time ago I had made a proposal (on
>     Translation-i18n)
>     > for a more substantial set of additions to Gettext, which would handle
>     > anything for which one can write down an algorithmic solution.
>     This proposal
>     > had gender-type examples, too. There was little response, and none
>     from the
>     > maintainer, so I took it as a insufficient interest to actually try
>     > implementing at some point. Maybe it makes sense to resubmit it
>     here now
>     > (with a bit of dusting off based on additional insights in the
>     meantime).
>     > I'll do this in another message.
>     >
> 
>     Having algorithmic language in translatations is an overkill in most
>     cases. You can't expect translators to be skilled coders or to work deep
>     through the intricacies of program they translate. In particular you
>     can't expect them to produce good code. Having bugs coming from a
>     translation to the language maintainer doesn't understand isn't
>     manageable. Also maintaining the parser is no easy task and would use up
>     too much time compared to very small benefit. In cases when number of
>     possible contexts is small and doesn't vary across languages, like
>     gender-aware translations, dcgettext with providing context is the way
>     to go. If you have something needing complicated language-depending
>     processing you should ask yourself whether you're doing something wrong
>     in the first place and if you could simplify the output, in the same
>     time making it more comprehensible. Also it has to be considered on
>     per-case basis. If it's something generic enough to be useful across
>     applications IMHO it could be considered for inclusion but something
>     which is too specific to one application it would be maintainance and
>     bug-hunting nightmare and is probably to be left in the program in
>     question.
> 
>     P.S: I'm not gettext maintainer.
> 
> 
> It seems that different languages has more differences than only
> gender-aware ones. I got several examples from linguistics that I have
> spoken to. For once, adjectives to objects in Dutch. "They are pretty"
> is different for men. women, and chairs.
> 
This is typically a case of inserting a word in a sentence. You can't do
it generically since it can have impact on whole sentence. In this case
we have grammatical gender (there are 3 of them in Dutch) but other word
characteristics may have influence as well. Like animated/not-animated
word or sounds at the beginning/end may influence sound harmony or
catenation. You have to stick to full sentences. If that's not possible
you have to look into why you have to generate and solution appropriate
for problem at hand.
One possible problem is inserting personal name into a sentence. Some
languages have variable names which change depending on their function
in the sentence. Trouble is that it may be quite irregular and poorly
integrate foreign names.
> There's a project[1] from Wikimedia that tries to solve some of these
> problems. I haven't had the time to dig much into it but it has this[2]
> nice example which gettext can't do "out-of-the-box" (or maybe is not
> intended to?). The project is called jQuery.i18n and is only implemented
> in jQuery/JavaScript for web applications.
> 
> [1]: https://github.com/wikimedia/jquery.i18n
> [2]: http://thottingal.in/projects/js/jquery.i18n/demo/


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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