<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8"> <META NAME="GENERATOR" CONTENT="GtkHTML/3.3.2"> </HEAD> <BODY> On Tue, 2005-05-03 at 22:45 +1000, Asgeir Frimannsson wrote: Hi, <BLOCKQUOTE TYPE=CITE> <PRE> > I see that you base everything on Gettext API. Isn't it too dangerous to > assume that all files were originated in C programs? We're basing the guide on GNU Gettext - and the tools provided by GNU Gettext. Not any 3rd party ad-hoc extraction tools out there (there are plenty). With the Gettext API I mean the one in use by gettext when extracting from c, c++, php, sh, python and other formats the toolkit supports. </PRE> </BLOCKQUOTE> <PRE> </PRE> Why limit the scope of the guide? <BLOCKQUOTE TYPE=CITE> <PRE> > Some PO files are generated from XML documents. If at reverse conversion > you add the sequence "\n" whenever you find a linefeed, the result will > be a mess. PO files generated from XML documents are excluded - they are plain simply evil. </PRE> </BLOCKQUOTE> Unfortunately, many translation projects like Fedora --where I participate as translator-- include PO files generated from XML files. I still need to translate those PO files and I want to keep using my XLIFF editor for that. <BLOCKQUOTE TYPE=CITE> <PRE> Let us keep to PO for Software Message catalogs in this discussion. </PRE> </BLOCKQUOTE> Please don't do it. We are here to provide tools for translators Translators never generate the PO files, they simply download from a repository. So, if the file was generated from XML or whatever and a filter like yours is used, the result of the translation process will be terrible. The consequences will be against us: people will not convert from PO to XLIFF because the results will be bad. Rodolfo <TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%"> <TR> <TD> -- Rodolfo M. Raya <<A HREF="mailto:rodolfo@heartsome.net">rodolfo@heartsome.net</A>> Heartsome Holdings Pte Ltd </TD> </TR> </TABLE> </BODY> </HTML>