Format proposals

About our today's talk on file formats, you can read the [XML page on Wikipedia]

Parallel Wikis

I think that the wiki for the project should be only one, we are allowed to put test versions or proposals... (Martino)

I agree. We should probably stick to one wiki because it will get confusing otherwise - sorry, Carlo. Leo 01:52, 27 April 2006 (CEST)

Comments

So, as you can see I found few positive aspects for XML and few negative for PO. I don't want to advertise the PO format, so if you know/find aspects that I haven't mentioned, don't hesitate to add them! Etienner 17:09, 28 April 2006 (CEST)

Partiality, unicode and readability

It seems like these judgments are a bit "partial", but that's normal... maybe someone sustaining XML should put his opinion... and about readability: I don't think it's really a big problem... if it is, it can be solved by writing a simple "translator" to "human readable" Unicode: isn't it a big advantage that XML fully supports unicode? Cconti

I know, the judgments are partial, but this is the great advantage of wiki pages combined with the comunity that uses them: the more it is modified, the more pages get unpartial...

For the human readability, you are right.

Unicode IS a big advantage, but UTF-8 is a unicode encoding, and it appears as last entry in the list. Etienne ^talk

My opinion on the whole thing: We do not really need to build hierarchies, which is what XML would be good at.

On the other hand, we have an XML parser in Eiffel already, and despite there being gettext under a free license it is probably far better to avoid new external dependancies.

If cats could talk they would chose XML-described catfood. In this case.

Because if cats could talk, they could read the ingredients of catfood, too. But not if they are XML-described... :-) ETN ^talk

Licensing

We will have to write our own .po parser because ISE will want copyright assignent (or at the least BSD licensing) & we can't just use gettext because there is probably no way to make this an optional addon. Leo 19:29, 28 April 2006 (CEST)

I'm not an expert on licensing stuff so I'v copied from the gettext manual and pasted it here.

Some people wonder if using GNU gettext necessarily brings their package under the protective wing of the GNU General Public License or the GNU Library General Public License, when they do not want to make their program free, or want other kinds of freedom. The simplest answer is "normally not".

The GNU gettext library, i.e. the contents of libintl, is covered by the GNU Library General Public License. The rest of the GNU gettext package is covered by the GNU General Public License.

The mere marking of localizable strings in a package, or conditional inclusion of a few lines for initialization, is not really including GPL'ed or LGPL'ed code. However, since the localization routines in libintl are under the LGPL, the LGPL needs to be considered. It gives the right to distribute the complete unmodified source of libintl evehttp://eiffelsoftware.origo.ethz.ch/index.php?title=Talk:Internationalization/file_format&action=editn with non-free programs. It also gives the right to use libintl as a shared library, even for non-free programs. But it gives the right to use libintl as a static library or to incorporate libintl into another library only to free software. Etienner 19:49, 28 April 2006 (CEST)

There exists a BSD-licensed gettext implementation from the NetBSD project. --Thom 10:09, 29 April 2006 (CEST)

Thanks. I'll have a look at it. Leo 15:15, 29 April 2006 (CEST)

Voting

I think there are now enough information for a voting on the file format...

Despite the votation the file format will still be discussed (with argumentations) at the next meeting. --Carlo 22:43, 2 May 2006 (CEST)