Re: [Proposal] Merging the gettext branch into trunk

From: Urmas <davian818_at_gmail.com>
Date: Thu Apr 28 2011 - 23:47:56 CEST

From: "Kathiravelu Pradeeban" <kk.pradeeban@gmail.com>
Subject: [Proposal] Merging the gettext branch into trunk

>
> Hi,
> As the advantages of using gettext have been discussed and debated a
> year ago in this mail thread, I would like to see a merge of the
> gettext work done by Keith Bowes into the trunk. The gettext branch is
> located at [1], and we also thought that it would be beneficial to
> merge sooner as Aseem starts porting AbiWord to gtk-3. There may still
> be a few pending issues hither and thither which we may need to fix
> before and/or sooner after the merge.
>
> Keith, would you be able to work more on this in your spare time
> towards the merge? Is there any concern that you see regarding the
> merge?
> Suggestions and thoughts are welcome.
>
> [1] http://svn.abisource.com/abiword/branches/gsoc2009gettext/
>
> Thank you.
> Regards,
> Pradeeban.
>
> On Tue, Nov 17, 2009 at 8:02 PM, Dominic Lachowicz
> <domlachowicz@gmail.com> wrote:
>>
>> Several benefits include:
>>
>> * Many (the majority?) of translators are familiar with and already use gettext
>> * There are tools (including automated tools) that work with gettext
>> * The code is maintained by someone other than us
>>
>> You get none of those benefits with a proprietary format.
>>
>> 2009/11/17 SSK <eskaer_spamsink@ngs.ru>:
>>> ----- Original Message -----
>>> From: "J.M. Maurer" <uwog@uwog.net>
>>> To: <abiword-dev@abisource.com>
>>> Sent: Tuesday, November 17, 2009 4:03 AM
>>> Subject: Roadmap for AbiWord 3.0
>>>
>>>>
>>>> After AbiWord 2.8 comes AbiWord 3.0 (let's skip 2.10, people will be
>>>> confused), which means we need to decide what to put in it.
>>>>
>>>> Fridrich already committed some work towards a Windows 64 bit port, so
>>>> that will be in 3.0 to start.
>>>>
>>>> Then we have some stuff lined up in branches that we need to decide upon
>>>> when to merge:
>>>>
>>>> 1. gsoc2009gettext - port abiword to gettext, making plugins localizable
>>>> 2. gsoc2009unicode - make the Win32 port a true unicode application
>>>> 3. gsoc2009tablelayout - improve (table layout) performance, includes
>>>> the new PieceTable.
>>>
>>>
>>> Why use gettext? In my opinion, it is not an elegant system: it stores translations in binary format, which requires special development tools to (de)compile; also it has some ugly hacks like embedding of non-printable characters in keywords to prevent undesired string merging, and run-time interpreting of expression for plural form(s). The current *.string format is good enough: usable and clear.
>>

Is it ready? Also, I believe in that case we should use string string identifiers in source instead of English text, to save us from dealing with message contexts.
Received on Thu Apr 28 23:48:08 2011

This archive was generated by hypermail 2.1.8 : Thu Apr 28 2011 - 23:48:08 CEST