Considerations needed to propose a binary dependency (Gettext)

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Considerations needed to propose a binary dependency (Gettext)

Ismael Venegas Castelló
Hello everyone!

In this case I'm interested in making Julia use and build GNU Gettext by default along with the other dependencies it currently has. I want to be able to use gettext in order to internationalize Julia, currently I'm working with the JuliaParser.jl (which I assume someday would replace the Femtolisp one?) something like this:

msgid ""
msgstr ""
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Language: es\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

msgid "true"
msgstr "verdadero"

msgid "false"
msgstr "falso"

msgid "begin"
msgstr "empezar"

msgid "while"
msgstr "mientras"

msgid "if"
msgstr "si"

msgid "for"
msgstr "por"

msgid "try"
msgstr "intentar"

msgid "return"
msgstr "retornar"

msgid "break"
msgstr "romper"

msgid "continue"
msgstr "continuar"

msgid "function"
msgstr "función"

msgid "stagedfunction"
msgstr "funciónetapas"

msgid "quote"
msgstr "comilla"

msgid "let"
msgstr "sea"

msgid "abstract"
msgstr "abstracto"

msgid "typealias"
msgstr "aliastipo"

msgid "type"
msgstr "tipo"

msgid "bitstype"
msgstr "tipobits"

msgid "immutable"
msgstr "inmutable"

msgid "ccall"
msgstr "llamarc"

msgid "do"
msgstr "hacer"

msgid "module"
msgstr "módulo"

msgid "baremodule"
msgstr "módulorazo"

msgid "using"
msgstr "usando"

msgid "import"
msgstr "importar"

msgid "export"
msgstr "exportar"

msgid "importall"
msgstr "importartodo"

msgid "else"
msgstr "sino"

msgid "elseif"
msgstr "osi"

msgid "end"
msgstr "fin"

msgid "catch"
msgstr "atrapar"

msgid "finally"
msgstr "finalmente"

But currently Gettext.jl uses PyCall. Anyway I also want to be able to translate all strings in Julia (errors, warnings, infos, show, repr, etc.) not only the reserved words. This would be part of a JulEP which I'm planning.

Currently I'm trying to refactor JuliaParser.jl in order to make it more modular and to document it, so I can elaborate my final JulEP and propose merging this functionality into base JuliaParser and eventually into Julia itself.

Thanks in advance, cheers!
Reply | Threaded
Open this post in threaded view
|

Considerations needed to propose a binary dependency (Gettext)

Tony Kelman
Licensing and portability, mostly. GNU gettext is GPL which is not acceptable for new dependencies of base, unfortunately, unless there is a linking exception like libgit2 has. The other existing GPL dependencies of base are scheduled to be removed from base. If you can come up with a feasible design where internationalization happens as a plugin where the gettext library is not absolutely required but can be optionally added, that might work. Otherwise you'd need to find a BSD or MIT licensed implementation.
Reply | Threaded
Open this post in threaded view
|

Re: Considerations needed to propose a binary dependency (Gettext)

Milan Bouchet-Valat
Le mercredi 20 avril 2016 à 08:36 -0700, Tony Kelman a écrit :
> Licensing and portability, mostly. GNU gettext is GPL which is not
> acceptable for new dependencies of base, unfortunately, unless there
> is a linking exception like libgit2 has. The other existing GPL
> dependencies of base are scheduled to be removed from base. If you
> can come up with a feasible design where internationalization happens
> as a plugin where the gettext library is not absolutely required but
> can be optionally added, that might work. Otherwise you'd need to
> find a BSD or MIT licensed implementation.
I think I mentioned this in another thread, but libintl provides a BSD-
licensed implementation which is apparently more or less compatible
with gettext 0.18.1:
https://wiki.netbsd.org/projects/project/libintl/
https://gitlab.com/worr/libintl

Anyway, gettext is a typical case of an optional dependency: just
define a few fallbacks in the style of
_(x::AbstractString) = x

and you get a build without any dependency on gettext. You'd still need
it to manage translation files, but only for developers.


Regards
Reply | Threaded
Open this post in threaded view
|

Re: Considerations needed to propose a binary dependency (Gettext)

Ismael Venegas Castelló
Thank you very much Milan, yeah I had forgoten you mentioned it, is this legaly the same conditions as in BSD? I don't know to much about this:

libintl is under the following copyright:

Copyright (c) 2000, 2001 Citrus Project
Copyright (c) 2015 William Orr <will@worrbase.com>
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification
, are permitted provided that the following conditions
are met
:
1. Redistributions of source code must retain the above copyright
   notice
, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice
, this list of conditions and the following disclaimer in the
   documentation
and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS
``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES
, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED
.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT
, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES
; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY
, WHETHER IN CONTRACT, STRICT
LIABILITY
, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE
, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE
.

All other files (parts of NetBSD's libc) are under their original license in
the headers of the appropriate files.


* https://gitlab.com/worr/libintl/raw/master/LICENSE

I just want to make sure, this would be a BSD Clause 2 simplified license, am I right ans so is ok?  

https://en.wikipedia.org/wiki/BSD_licenses#2-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29


El miércoles, 20 de abril de 2016, 11:03:40 (UTC-5), Milan Bouchet-Valat escribió:
Le mercredi 20 avril 2016 à 08:36 -0700, Tony Kelman a écrit :
> Licensing and portability, mostly. GNU gettext is GPL which is not
> acceptable for new dependencies of base, unfortunately, unless there
> is a linking exception like libgit2 has. The other existing GPL
> dependencies of base are scheduled to be removed from base. If you
> can come up with a feasible design where internationalization happens
> as a plugin where the gettext library is not absolutely required but
> can be optionally added, that might work. Otherwise you'd need to
> find a BSD or MIT licensed implementation.
I think I mentioned this in another thread, but libintl provides a BSD-
licensed implementation which is apparently more or less compatible
with gettext 0.18.1:
<a href="https://wiki.netbsd.org/projects/project/libintl/" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fwiki.netbsd.org%2Fprojects%2Fproject%2Flibintl%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNH82S7boviriEaDEsUkljCRy2k5Dg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fwiki.netbsd.org%2Fprojects%2Fproject%2Flibintl%2F\46sa\75D\46sntz\0751\46usg\75AFQjCNH82S7boviriEaDEsUkljCRy2k5Dg&#39;;return true;">https://wiki.netbsd.org/projects/project/libintl/
<a href="https://gitlab.com/worr/libintl" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fgitlab.com%2Fworr%2Flibintl\46sa\75D\46sntz\0751\46usg\75AFQjCNGxvD7KN4TP6dInqWtyePeXB7wi8g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\75https%3A%2F%2Fgitlab.com%2Fworr%2Flibintl\46sa\75D\46sntz\0751\46usg\75AFQjCNGxvD7KN4TP6dInqWtyePeXB7wi8g&#39;;return true;">https://gitlab.com/worr/libintl

Anyway, gettext is a typical case of an optional dependency: just
define a few fallbacks in the style of
_(x::AbstractString) = x

and you get a build without any dependency on gettext. You'd still need
it to manage translation files, but only for developers.


Regards
Reply | Threaded
Open this post in threaded view
|

Re: Considerations needed to propose a binary dependency (Gettext)

jrgarrison
If my memory serves correctly, the gettext code wrapped by Gettext.jl is actually built in to python, which is licensed permissively.  It happens to be compatible with GNU gettext, but it does not depend on it.  I believe it should be possible to translate this code to Julia (issue #1 of Gettext.jl).

On Wed, Apr 20, 2016 at 9:46 AM, Ismael Venegas Castelló <[hidden email]> wrote:
Thank you very much Milan, yeah I had forgoten you mentioned it, is this legaly the same conditions as in BSD? I don't know to much about this:

libintl is under the following copyright:

Copyright (c) 2000, 2001 Citrus Project
Copyright (c) 2015 William Orr <will@worrbase.com>
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification
, are permitted provided that the following conditions
are met
:
1. Redistributions of source code must retain the above copyright
   notice
, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice
, this list of conditions and the following disclaimer in the
   documentation
and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS
``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES
, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED
.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT
, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES
; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY
, WHETHER IN CONTRACT, STRICT
LIABILITY
, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE
, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE
.

All other files (parts of NetBSD's libc) are under their original license in
the headers of the appropriate files.



I just want to make sure, this would be a BSD Clause 2 simplified license, am I right ans so is ok?  



El miércoles, 20 de abril de 2016, 11:03:40 (UTC-5), Milan Bouchet-Valat escribió:
Le mercredi 20 avril 2016 à 08:36 -0700, Tony Kelman a écrit :
> Licensing and portability, mostly. GNU gettext is GPL which is not
> acceptable for new dependencies of base, unfortunately, unless there
> is a linking exception like libgit2 has. The other existing GPL
> dependencies of base are scheduled to be removed from base. If you
> can come up with a feasible design where internationalization happens
> as a plugin where the gettext library is not absolutely required but
> can be optionally added, that might work. Otherwise you'd need to
> find a BSD or MIT licensed implementation.
I think I mentioned this in another thread, but libintl provides a BSD-
licensed implementation which is apparently more or less compatible
with gettext 0.18.1:
https://wiki.netbsd.org/projects/project/libintl/
https://gitlab.com/worr/libintl

Anyway, gettext is a typical case of an optional dependency: just
define a few fallbacks in the style of
_(x::AbstractString) = x

and you get a build without any dependency on gettext. You'd still need
it to manage translation files, but only for developers.


Regards

Reply | Threaded
Open this post in threaded view
|

Re: Considerations needed to propose a binary dependency (Gettext)

Milan Bouchet-Valat
In reply to this post by Ismael Venegas Castelló
Le mercredi 20 avril 2016 à 09:46 -0700, Ismael Venegas Castelló a écrit :

> Thank you very much Milan, yeah I had forgoten you mentioned it, is
> this legaly the same conditions as in BSD? I don't know to much about
> this:
>
> libintl is under the following copyright:
>
> Copyright (c) 2000, 2001 Citrus Project
> Copyright (c) 2015 William Orr <[hidden email]>
> All rights reserved.
>
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that the following conditions
> are met:
> 1. Redistributions of source code must retain the above copyright
>    notice, this list of conditions and the following disclaimer.
> 2. Redistributions in binary form must reproduce the above copyright
>    notice, this list of conditions and the following disclaimer in the
>    documentation and/or other materials provided with the distribution.
>
> THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> SUCH DAMAGE.
>
> All other files (parts of NetBSD's libc) are under their original license in
> the headers of the appropriate files.
>
>
> * https://gitlab.com/worr/libintl/raw/master/LICENSE
>
> I just want to make sure, this would be a BSD Clause 2 simplified
> license, am I right ans so is ok?  
>
> https://en.wikipedia.org/wiki/BSD_licenses#2-
> clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.
> 22.29
Yes, as you can see, this is exactly the text of the 2-clause BSD
license. So you're safe.


Regards

>
> > Le mercredi 20 avril 2016 à 08:36 -0700, Tony Kelman a écrit : 
> > > Licensing and portability, mostly. GNU gettext is GPL which is not 
> > > acceptable for new dependencies of base, unfortunately, unless there 
> > > is a linking exception like libgit2 has. The other existing GPL 
> > > dependencies of base are scheduled to be removed from base. If you 
> > > can come up with a feasible design where internationalization happens 
> > > as a plugin where the gettext library is not absolutely required but 
> > > can be optionally added, that might work. Otherwise you'd need to 
> > > find a BSD or MIT licensed implementation. 
> > I think I mentioned this in another thread, but libintl provides a BSD- 
> > licensed implementation which is apparently more or less compatible 
> > with gettext 0.18.1: 
> > https://wiki.netbsd.org/projects/project/libintl/ 
> > https://gitlab.com/worr/libintl 
> >
> > Anyway, gettext is a typical case of an optional dependency: just 
> > define a few fallbacks in the style of 
> > _(x::AbstractString) = x 
> >
> > and you get a build without any dependency on gettext. You'd still need 
> > it to manage translation files, but only for developers. 
> >
> >
> > Regards 
Reply | Threaded
Open this post in threaded view
|

Re: Considerations needed to propose a binary dependency (Gettext)

Ismael Venegas Castelló
In reply to this post by jrgarrison
Thank you very much everyone for your input, Jim I wasn't sure about the Python license, thanks for clearing that out, I was under the impression that basing Julia code in Python standard library code was a no no.

Once again just to make sure, the license in the root of their git repository is the one that also covers this file and is ok:

* https://github.com/python/cpython/blob/master/LICENSE

So many licensing details, if this is true, then this is the best version to port into Julia, great!

El miércoles, 20 de abril de 2016, 12:09:07 (UTC-5), Jim Garrison escribió:
If my memory serves correctly, the gettext code wrapped by Gettext.jl is actually built in to python, which is licensed permissively.  It happens to be compatible with GNU gettext, but it does not depend on it.  I believe it should be possible to translate this code to Julia (issue #1 of Gettext.jl).

On Wed, Apr 20, 2016 at 9:46 AM, Ismael Venegas Castelló <<a href="javascript:" target="_blank" gdf-obfuscated-mailto="601TVXP5AwAJ" rel="nofollow" onmousedown="this.href=&#39;javascript:&#39;;return true;" onclick="this.href=&#39;javascript:&#39;;return true;">ismael...@...> wrote:
Thank you very much Milan, yeah I had forgoten you mentioned it, is this legaly the same conditions as in BSD? I don't know to much about this:

libintl is under the following copyright:

Copyright (c) 2000, 2001 Citrus Project
Copyright (c) 2015 William Orr <will@worrbase.com>
All rights reserved.

Redistribution and use in source and binary forms, with or without
modification
, are permitted provided that the following conditions
are met
:
1. Redistributions of source code must retain the above copyright
   notice
, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
   notice
, this list of conditions and the following disclaimer in the
   documentation
and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS
``AS IS'' AND
ANY EXPRESS OR IMPLIED WARRANTIES
, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED
.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
FOR ANY DIRECT
, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
OR SERVICES
; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY
, WHETHER IN CONTRACT, STRICT
LIABILITY
, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE
, EVEN IF ADVISED OF THE POSSIBILITY OF
SUCH DAMAGE
.

All other files (parts of NetBSD's libc) are under their original license in
the headers of the appropriate files.


* <a href="https://gitlab.com/worr/libintl/raw/master/LICENSE" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgitlab.com%2Fworr%2Flibintl%2Fraw%2Fmaster%2FLICENSE\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEj2VHDN2A1Khm2DeFHN1Q6lLxeVA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgitlab.com%2Fworr%2Flibintl%2Fraw%2Fmaster%2FLICENSE\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNEj2VHDN2A1Khm2DeFHN1Q6lLxeVA&#39;;return true;">https://gitlab.com/worr/libintl/raw/master/LICENSE

I just want to make sure, this would be a BSD Clause 2 simplified license, am I right ans so is ok?  

<a href="https://en.wikipedia.org/wiki/BSD_licenses#2-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29" target="_blank" rel="nofollow" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FBSD_licenses%232-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFIiTshyJmVjrXZxZ08T_WAna4hrA&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fen.wikipedia.org%2Fwiki%2FBSD_licenses%232-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNFIiTshyJmVjrXZxZ08T_WAna4hrA&#39;;return true;">https://en.wikipedia.org/wiki/BSD_licenses#2-clause_license_.28.22Simplified_BSD_License.22_or_.22FreeBSD_License.22.29


El miércoles, 20 de abril de 2016, 11:03:40 (UTC-5), Milan Bouchet-Valat escribió:
Le mercredi 20 avril 2016 à 08:36 -0700, Tony Kelman a écrit :
> Licensing and portability, mostly. GNU gettext is GPL which is not
> acceptable for new dependencies of base, unfortunately, unless there
> is a linking exception like libgit2 has. The other existing GPL
> dependencies of base are scheduled to be removed from base. If you
> can come up with a feasible design where internationalization happens
> as a plugin where the gettext library is not absolutely required but
> can be optionally added, that might work. Otherwise you'd need to
> find a BSD or MIT licensed implementation.
I think I mentioned this in another thread, but libintl provides a BSD-
licensed implementation which is apparently more or less compatible
with gettext 0.18.1:
<a href="https://wiki.netbsd.org/projects/project/libintl/" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwiki.netbsd.org%2Fprojects%2Fproject%2Flibintl%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH82S7boviriEaDEsUkljCRy2k5Dg&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fwiki.netbsd.org%2Fprojects%2Fproject%2Flibintl%2F\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNH82S7boviriEaDEsUkljCRy2k5Dg&#39;;return true;">https://wiki.netbsd.org/projects/project/libintl/
<a href="https://gitlab.com/worr/libintl" rel="nofollow" target="_blank" onmousedown="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgitlab.com%2Fworr%2Flibintl\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxvD7KN4TP6dInqWtyePeXB7wi8g&#39;;return true;" onclick="this.href=&#39;https://www.google.com/url?q\x3dhttps%3A%2F%2Fgitlab.com%2Fworr%2Flibintl\x26sa\x3dD\x26sntz\x3d1\x26usg\x3dAFQjCNGxvD7KN4TP6dInqWtyePeXB7wi8g&#39;;return true;">https://gitlab.com/worr/libintl

Anyway, gettext is a typical case of an optional dependency: just
define a few fallbacks in the style of
_(x::AbstractString) = x

and you get a build without any dependency on gettext. You'd still need
it to manage translation files, but only for developers.


Regards

Reply | Threaded
Open this post in threaded view
|

Re: Considerations needed to propose a binary dependency (Gettext)

Páll Haraldsson
In reply to this post by Ismael Venegas Castelló
On Wednesday, April 20, 2016 at 2:24:08 PM UTC, Ismael Venegas Castelló wrote:
Hello everyone!

In this case I'm interested in making Julia use and build GNU Gettext by default along with the other dependencies it currently has. I want to be able to use gettext in order to internationalize Julia, currently I'm working with the JuliaParser.jl (which I assume someday would replace the Femtolisp one?) something like this:

msgid ""
msgstr ""
"MIME-Version: 1.0\n"
"Content-Type: text/plain; charset=UTF-8\n"
"Content-Transfer-Encoding: 8bit\n"
"Language: es\n"
"Plural-Forms: nplurals=2; plural=(n > 1);\n"

msgid "true"
msgstr "verdadero"

msgid "false"
msgstr "falso"

msgid "begin"
msgstr "empezar"

msgid "while"
msgstr "mientras"

msgid "if"
msgstr "si"

msgid "for"
msgstr "por"

msgid "try"
msgstr "intentar"

msgid "return"
msgstr "retornar"

msgid "break"
msgstr "romper"

msgid "continue"
msgstr "continuar"

msgid "function"
msgstr "función"

msgid "stagedfunction"
msgstr "funciónetapas"

msgid "quote"
msgstr "comilla"

msgid "let"
msgstr "sea"

msgid "abstract"
msgstr "abstracto"

msgid "typealias"
msgstr "aliastipo"

msgid "type"
msgstr "tipo"

msgid "bitstype"
msgstr "tipobits"

msgid "immutable"
msgstr "inmutable"

msgid "ccall"
msgstr "llamarc"

msgid "do"
msgstr "hacer"

msgid "module"
msgstr "módulo"

msgid "baremodule"
msgstr "módulorazo"

msgid "using"
msgstr "usando"

msgid "import"
msgstr "importar"

msgid "export"
msgstr "exportar"

msgid "importall"
msgstr "importartodo"

msgid "else"
msgstr "sino"

msgid "elseif"
msgstr "osi"

msgid "end"
msgstr "fin"

msgid "catch"
msgstr "atrapar"

msgid "finally"
msgstr "finalmente"

But currently Gettext.jl uses PyCall.

I do support you wanting GetText (or libintl or whatever) working (for Julia programs, if not the implementations itself).

Anyway I also want to be able to translate all strings in Julia (errors, warnings, infos, show, repr, etc.) not only the reserved words. This would be part of a JulEP which I'm planning.

I'm very conflicted on translated error [programmer] message etc.. [what will be the burden on those only using English for core Julia developers?] I've seen e.g. German ones in Ubuntu, and it divides the world of support.. Maybe ok, if English-language error is appended (prepended?).

There is an Icelandic language, Fjölnir (and Arabic, Chinese? etc.) that is not a huge success.. Maybe your plan will work to get beginners working, but wouldn't they want to learn the standard syntax anyway later? I understand Ruby has more (than Python) symbolic code over English-keywords, since Matz is Japanese..

Could some tool/macro? translate your source code to/from English?


Currently I'm trying to refactor JuliaParser.jl in order to make it more modular and to document it, so I can elaborate my final JulEP and propose merging this functionality into base JuliaParser and eventually into Julia itself.

Thanks in advance, cheers!
Reply | Threaded
Open this post in threaded view
|

Re: Considerations needed to propose a binary dependency (Gettext)

Páll Haraldsson
In reply to this post by Ismael Venegas Castelló
On Wednesday, April 20, 2016 at 7:49:17 PM UTC, Ismael Venegas Castelló wrote:
I was under the impression that basing Julia code in Python standard library code was a no no.

https://www.openhub.net/p/JuliaLang/analyses/latest/languages_summary

I was little surprised seeing Python at 18,630 lines of code (second after "Mostly written in C")..

I believe this isn't true at all.. and should say Julia(?) as looks sufficiently similar?