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: Sun, 19 May 2013 14:07:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12

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

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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