You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Erik Huelsmann <e....@gmx.net> on 2004/04/16 21:32:23 UTC
client side l10n: remaining issues?
In order to get a localized Subversion release, several steps have to be
taken. With this e-mail I hope to generate the discussion which will result
in a list of all issues involved.
The requirements are:
a) localized versions on all OS-es which Subversion runs on (*nix, Windows,
...)
b) messages which are UTF-8 internally in Subversion, as all other internal
internationalized data
c) no duplication of supporting libraries (for example iconv as mentioned by
Brane)
d) minimal new code written for Subversion (the desire not to write our own
gettext implementation comes to mind)
e) the ability to build without localization
The steps to be taken to get localization into Subversion (not neccesarily
in the order mentioned):
1) Adjust the build system
(autoconf system done; windows side isn't)
2) Mark strings to be translated
(partially committed; more to come)
3) Decide on which system to use
(gettext seems to be the choice; what are the windows implications of it?!
are there any other possible choices?)
4) Produce a template file from which to translate
(not available yet)
5) Start translation
(started for Spanish and Swedish; other languages pending)
6) Resolve any problems which might appear in the above 5 steps
Anybody to add more items to this list?
To comment on (3) I must say I agree with Brane that it would be problematic
if two iconv libraries would be required to get gettext incorporated on
Windows. This is why I like Sander's idea of adding a libapr_l10n to apr (if
they want to accept that) to complete the already set of libraries (which
includes libapr_iconv ofcourse). Brane's desire not to want to link in more
libraries seemed like an extra argument to go this way. Yet doing so would
definitely conflict with requirement (d).
bye,
Erik.
--
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/info
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: client side l10n: remaining issues?
Posted by Branko Čibej <br...@xbc.nu>.
Peter N. Lundblad wrote:
>On Tue, 20 Apr 2004, [UTF-8] Branko Ä^Libej wrote:
>
>
>
>>Peter N. Lundblad wrote:
>>
>>
>>
>>>When I worked on OpenJade some years ago, we used gettext for l10n, but
>>>not on Windows. INstead, we used a script to put the translations in
>>>Windows resource files. We could do womething similar, and compile each
>>>translation into its own DLL. Then we wouldn't need the gettext runtime at
>>>all. ONe would still need the tools for development however.
>>>
>>>
>>>
>>>
>>Please no, that's a most horrible idea. Gettext is more than just
>>message translation; you'd have to reimplement the whole ngettext logic
>>on Windows, for example, and we _don't_ want to have this kind of code
>>in Subversion.
>>
>>
>>
>Good point if we ever use ngettext. Is that available in more gettexts
>than GNU gettext?
>
>
I understand the latest Solaris version supports it.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: client side l10n: remaining issues?
Posted by "Peter N. Lundblad" <lu...@linux.nu>.
On Tue, 20 Apr 2004, [UTF-8] Branko Ä^Libej wrote:
> Peter N. Lundblad wrote:
>
> >When I worked on OpenJade some years ago, we used gettext for l10n, but
> >not on Windows. INstead, we used a script to put the translations in
> >Windows resource files. We could do womething similar, and compile each
> >translation into its own DLL. Then we wouldn't need the gettext runtime at
> >all. ONe would still need the tools for development however.
> >
> >
> Please no, that's a most horrible idea. Gettext is more than just
> message translation; you'd have to reimplement the whole ngettext logic
> on Windows, for example, and we _don't_ want to have this kind of code
> in Subversion.
>
Good point if we ever use ngettext. Is that available in more gettexts
than GNU gettext?
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: client side l10n: remaining issues?
Posted by Branko Čibej <br...@xbc.nu>.
Peter N. Lundblad wrote:
>On Fri, 16 Apr 2004, Erik Huelsmann wrote:
>
>...
>
>
>>c) no duplication of supporting libraries (for example iconv as mentioned by
>>Brane)
>>d) minimal new code written for Subversion (the desire not to write our own
>>gettext implementation comes to mind)
>>
>>
>...
>
>
>>To comment on (3) I must say I agree with Brane that it would be problematic
>>if two iconv libraries would be required to get gettext incorporated on
>>Windows. This is why I like Sander's idea of adding a libapr_l10n to apr (if
>>they want to accept that) to complete the already set of libraries (which
>>includes libapr_iconv ofcourse). Brane's desire not to want to link in more
>>libraries seemed like an extra argument to go this way. Yet doing so would
>>definitely conflict with requirement (d).
>>
>>
>>
>
>This idea might be to "reinvent the wheel", but anyway...
>
>When I worked on OpenJade some years ago, we used gettext for l10n, but
>not on Windows. INstead, we used a script to put the translations in
>Windows resource files. We could do womething similar, and compile each
>translation into its own DLL. Then we wouldn't need the gettext runtime at
>all. ONe would still need the tools for development however.
>
>
Please no, that's a most horrible idea. Gettext is more than just
message translation; you'd have to reimplement the whole ngettext logic
on Windows, for example, and we _don't_ want to have this kind of code
in Subversion.
In the absence of apr_libintl, we'll use gettext's libintl.
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: client side l10n: remaining issues?
Posted by "Peter N. Lundblad" <lu...@linux.nu>.
On Fri, 16 Apr 2004, Erik Huelsmann wrote:
...
>
> c) no duplication of supporting libraries (for example iconv as mentioned by
> Brane)
> d) minimal new code written for Subversion (the desire not to write our own
> gettext implementation comes to mind)
...
> To comment on (3) I must say I agree with Brane that it would be problematic
> if two iconv libraries would be required to get gettext incorporated on
> Windows. This is why I like Sander's idea of adding a libapr_l10n to apr (if
> they want to accept that) to complete the already set of libraries (which
> includes libapr_iconv ofcourse). Brane's desire not to want to link in more
> libraries seemed like an extra argument to go this way. Yet doing so would
> definitely conflict with requirement (d).
>
This idea might be to "reinvent the wheel", but anyway...
When I worked on OpenJade some years ago, we used gettext for l10n, but
not on Windows. INstead, we used a script to put the translations in
Windows resource files. We could do womething similar, and compile each
translation into its own DLL. Then we wouldn't need the gettext runtime at
all. ONe would still need the tools for development however.
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: client side l10n: remaining issues?
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Friday, April 16, 2004 11:44 PM +0200 Erik Huelsmann
<e....@gmx.net> wrote:
>> 3) Decide on which system to use
>> (gettext seems to be the choice; what are the windows implications of
>> it?!
>> are there any other possible choices?)
Win32 does have GNU gettext available. No real other choices here. Rewriting
gettext to be fully BSD is an option, but one that I'd rather avoid. Yet, if
we have to make changes to it, we're likely going to have throw out all of GNU
gettext. So, I'd rather live with any issues with GNU gettext. (Noting that
Solaris 9's gettext is also suitable for us.)
>> 4) Produce a template file from which to translate
>> (not available yet)
The es.po file is a start.
> 7) If the system needs initialization (which gettext does; think
> binddomain):
> How should this initialization take place? Do we add a new function to
> libsvn_subr to initialize the localization library, or do we depend on the
> client being initialized cf. some prescribed recipe?
This is already done in the svn_cmdline_init in libsvn_subr. Or something
like that. But, this is the standard entry point that we require for our
applications. Hmm. We need to do something for the bindings. Hmm. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: client side l10n: remaining issues?
Posted by Erik Huelsmann <e....@gmx.net>.
> 1) Adjust the build system
> (autoconf system done; windows side isn't)
> 2) Mark strings to be translated
> (partially committed; more to come)
> 3) Decide on which system to use
> (gettext seems to be the choice; what are the windows implications of
> it?!
> are there any other possible choices?)
> 4) Produce a template file from which to translate
> (not available yet)
> 5) Start translation
> (started for Spanish and Swedish; other languages pending)
> 6) Resolve any problems which might appear in the above 5 steps
>
> Anybody to add more items to this list?
Hmm; I might add one myself:
7) If the system needs initialization (which gettext does; think
binddomain):
How should this initialization take place? Do we add a new function to
libsvn_subr to initialize the localization library, or do we depend on the
client being initialized cf. some prescribed recipe?
bye,
Erik.
--
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/info
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: client side l10n: remaining issues?
Posted by "Peter N. Lundblad" <lu...@linux.nu>.
On Fri, 16 Apr 2004, Nicolás Lichtmaier wrote:
>
> >In order to get a localized Subversion release, several steps have to be
> >taken. With this e-mail I hope to generate the discussion which will result
> >in a list of all issues involved.
> >
> >The requirements are:
> >
> >
>
> d) Enhance the build system to provide for easy generation of the .pot
> file which is the source for new translations. This file is created by
> the xgettext utility and it should be uncluded in the tar.gz releases.
> In an early message I've posted a script that does that.
Could you please repost a link to that mail?
Regards,
//Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: client side l10n: remaining issues?
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>In order to get a localized Subversion release, several steps have to be
>taken. With this e-mail I hope to generate the discussion which will result
>in a list of all issues involved.
>
>The requirements are:
>
>
d) Enhance the build system to provide for easy generation of the .pot
file which is the source for new translations. This file is created by
the xgettext utility and it should be uncluded in the tar.gz releases.
In an early message I've posted a script that does that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org