[PlanetCCRMA] Any Spanish-speaking Planet CCRMA users out
there?
Andrew Wilson
djazz@myrealbox.com
Wed Sep 29 18:36:01 2004
--=-EJWonq2KxRUb6vNN0KVv
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Guys,
Just some comments from the sidelines. I think the "official" linux way
of approaching this problem is to use docbook for all the
documentation. This already has multi-language support and easily
generates output for html, pdf or whatever you want. The layout of the
existing planet documentation is uite straight forward and wouldn't be
that difficult to convert. The files are still text and this would then
open up access to all the various docbook tools out there for indexing
etc. (Fernando: I you want to go this way, I'd offer to do the initial
conversion for you)
The downside of course is that docbook files are xml which can be
tedious. There are other tools like lyx which help a lot, but I find
it's just as fast to edit the text docbook files.
To stay with latex, I think you would have to think about using a
pre-processor such as m4. For a previous project, I have also done a
search and latex2html seems to be the best tool around. All the
development effort seems to be going into the various docbook related
tools.
Cheers,
Andrew
On Thu, 2004-09-30 at 04:02, Fernando Pablo Lopez-Lezcano wrote:
> On Tue, 2004-09-28 at 08:30, hpsilva@servidor.unam.mx wrote:
> > I was wondering if there are any Spanish-speaking or more especifically
> > mexican users of Planet CCRMA lurking around here... I want to ask the
> > list if there is at all any interest in cooperating on a translation of
> > the software to Spanish. I would like to do this for our classes here in
> > Mexico City, as I feel learning is always easier in your native language
> > and this could give a boost to free software for music in our countries.
>
> It would be very interesting to do that (and also do something about
> French, there was an initiative a while back). I'm all for it.
>
> This is what I had in mind... (I've been rumiating about this for a
> while).
>
> The source to the Planet CCRMA web pages is written in latex. Latex has
> the advantage of being a "language" in the sense that I can define
> commands that help me automate many parts of the page creation
> process[*]. Anything automatic is good. When I want to update the site I
> just run the latex file through latex2html and copy the resulting web
> pages to their final location. This approach has the advantage of being
> very simple and very time efficient (for me - and that is very important
> :-).
>
> BTW, I would prefer to keep latex (or something very similar that is
> completely text based and programmable) in place as the main source for
> the web site. "Click-based" editing and interfacing is not really an
> option as it is more labor intensive.
>
> So the question is, how do we translate this (latex based source), and
> more important, how do we maintain the translations current and
> synchronized?
>
> One way would be to include the translations in the same source tree,
> probably having paragraph by paragraph translations. For example (just
> making up the syntax right now):
>
> \begin{language}
> \english
> some text and latex commands
> \spanish
> same text in spanish
> \end{language}
>
> (latex tags start with "\")
> and so on and so forth.
>
> So, two runs of latex2html would create two different versions of the
> web pages (the tags inside the language block would work as if's), one
> for each language. If a translation for a given paragraph does not exist
> the english version would be inserted as a default (till that paragraph
> is translated, after that the spanish version would be used). That would
> enable to have different languages up and running very fast, with a
> partial translation that would expand as translators add stuff to the
> source.
>
> If a change is made in the master ("english") language, then that block
> would be marked "\obsolete" or something like that, and english would be
> used again for that paragraph until the spanish (or whatever)
> translation catches up. Or the spanish would be marked visibly as
> obsolete and a link provided to the newer english version. Anything is
> possible as this is all text.
>
> This could all reside in cvs or subversion, of course.
>
> As to the implementation, as usual the devil is in the details. The main
> problem facing this approach is that latex2html does not support the
> latex \if conditionals. About a year ago, with this problem in mind, I
> tested other latex -> html translators and one of them (hevea, I seem to
> remember) did have the required support. But the visual quality of the
> generated html was not really satisfying (ie: it looked ugly on a
> browser).
>
> My current thinking was to implement a very simple "preprocessor"
> program that would process \if commands (or whatever is used in the
> end). So, running the latex source through the preprocessor for each
> language would create vanilla (no \if's) latex that latex2html can
> handle, with the proper mix of spanish and english, depending on which
> parts of the site have already been translated (and/or are in sync with
> the master english version).
>
> Thoughts?
> -- Fernando
>
> [*] This is what the entry for freqtweak looks like:
>
> \newcommand{\freqtweakver}{0.6.1-1}
> \newcommand{\freqtweakurl}{http://freqtweak.sourceforge.net/}
> \subsubsection{\label{freqtweak} \urllink {Freqtweak} {\freqtweakurl}}
> {\bf Version \freqtweakver\ \RHFCALL\ \JACK}
>
> \begin{quote}
> ``FreqTweak is a tool for FFT-based realtime audio spectral
> manipulation and display. It provides several algorithms for
> processing audio data in the frequency domain and a highly interactive
> GUI to manipulate the associated filters for each. It also provides
> high-resolution spectral displays in the form of scrolling-raster
> spectragrams and energy vs frequency plots displaying both pre- and
> post-processed spectra.''
> \end{quote}
>
> To install type:
>
> \begingreyfont
> \texttt{apt-get install freqtweak}\\
> \endgreyfont
>
> Freqtweak works through \htmlref {Jack} {jack} so you have to start it
> to make things happen.
>
> \textbf{ManPages:} \manpage {freqtweak} {1}
>
> \textbf{Rpms:}
>
> \beginsmallfont
> \begin{description}
> \item[\linkBaseAll{freqtweak}{\freqtweakver}]
> \item[\linkDebugAll{freqtweak}{\freqtweakver}]
> \item[\linkSourceAll{freqtweak}{\freqtweakver}]
> \end{description}
> \endsmallfont
>
>
> _______________________________________________
> PlanetCCRMA mailing list
> PlanetCCRMA@ccrma.stanford.edu
> http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma
>
--=-EJWonq2KxRUb6vNN0KVv
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit
<!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.0.10">
</HEAD>
<BODY>
Guys,<BR>
<BR>
Just some comments from the sidelines. I think the "official" linux way of approaching this problem is to use docbook for all the documentation. This already has multi-language support and easily generates output for html, pdf or whatever you want. The layout of the existing planet documentation is uite straight forward and wouldn't be that difficult to convert. The files are still text and this would then open up access to all the various docbook tools out there for indexing etc. (Fernando: I you want to go this way, I'd offer to do the initial conversion for you)<BR>
<BR>
The downside of course is that docbook files are xml which can be tedious. There are other tools like lyx which help a lot, but I find it's just as fast to edit the text docbook files.<BR>
<BR>
To stay with latex, I think you would have to think about using a pre-processor such as m4. For a previous project, I have also done a search and latex2html seems to be the best tool around. All the development effort seems to be going into the various docbook related tools.<BR>
<BR>
Cheers,<BR>
Andrew<BR>
<BR>
On Thu, 2004-09-30 at 04:02, Fernando Pablo Lopez-Lezcano wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE><FONT COLOR="#737373"><I>On Tue, 2004-09-28 at 08:30, hpsilva@servidor.unam.mx wrote:
> I was wondering if there are any Spanish-speaking or more especifically
> mexican users of Planet CCRMA lurking around here... I want to ask the
> list if there is at all any interest in cooperating on a translation of
> the software to Spanish. I would like to do this for our classes here in
> Mexico City, as I feel learning is always easier in your native language
> and this could give a boost to free software for music in our countries.
It would be very interesting to do that (and also do something about
French, there was an initiative a while back). I'm all for it.
This is what I had in mind... (I've been rumiating about this for a
while).
The source to the Planet CCRMA web pages is written in latex. Latex has
the advantage of being a "language" in the sense that I can define
commands that help me automate many parts of the page creation
process[*]. Anything automatic is good. When I want to update the site I
just run the latex file through latex2html and copy the resulting web
pages to their final location. This approach has the advantage of being
very simple and very time efficient (for me - and that is very important
:-).
BTW, I would prefer to keep latex (or something very similar that is
completely text based and programmable) in place as the main source for
the web site. "Click-based" editing and interfacing is not really an
option as it is more labor intensive.
So the question is, how do we translate this (latex based source), and
more important, how do we maintain the translations current and
synchronized?
One way would be to include the translations in the same source tree,
probably having paragraph by paragraph translations. For example (just
making up the syntax right now):
\begin{language}
\english
some text and latex commands
\spanish
same text in spanish
\end{language}
(latex tags start with "\")
and so on and so forth.
So, two runs of latex2html would create two different versions of the
web pages (the tags inside the language block would work as if's), one
for each language. If a translation for a given paragraph does not exist
the english version would be inserted as a default (till that paragraph
is translated, after that the spanish version would be used). That would
enable to have different languages up and running very fast, with a
partial translation that would expand as translators add stuff to the
source.
If a change is made in the master ("english") language, then that block
would be marked "\obsolete" or something like that, and english would be
used again for that paragraph until the spanish (or whatever)
translation catches up. Or the spanish would be marked visibly as
obsolete and a link provided to the newer english version. Anything is
possible as this is all text.
This could all reside in cvs or subversion, of course.
As to the implementation, as usual the devil is in the details. The main
problem facing this approach is that latex2html does not support the
latex \if conditionals. About a year ago, with this problem in mind, I
tested other latex -> html translators and one of them (hevea, I seem to
remember) did have the required support. But the visual quality of the
generated html was not really satisfying (ie: it looked ugly on a
browser).
My current thinking was to implement a very simple "preprocessor"
program that would process \if commands (or whatever is used in the
end). So, running the latex source through the preprocessor for each
language would create vanilla (no \if's) latex that latex2html can
handle, with the proper mix of spanish and english, depending on which
parts of the site have already been translated (and/or are in sync with
the master english version).
Thoughts?
-- Fernando
[*] This is what the entry for freqtweak looks like:
\newcommand{\freqtweakver}{0.6.1-1}
\newcommand{\freqtweakurl}{</FONT><A HREF="http://freqtweak.sourceforge.net/"><U>http://freqtweak.sourceforge.net/</U></A><FONT COLOR="#737373">}
\subsubsection{\label{freqtweak} \urllink {Freqtweak} {\freqtweakurl}}
{\bf Version \freqtweakver\ \RHFCALL\ \JACK}
\begin{quote}
``FreqTweak is a tool for FFT-based realtime audio spectral
manipulation and display. It provides several algorithms for
processing audio data in the frequency domain and a highly interactive
GUI to manipulate the associated filters for each. It also provides
high-resolution spectral displays in the form of scrolling-raster
spectragrams and energy vs frequency plots displaying both pre- and
post-processed spectra.''
\end{quote}
To install type:
\begingreyfont
\texttt{apt-get install freqtweak}\\
\endgreyfont
Freqtweak works through \htmlref {Jack} {jack} so you have to start it
to make things happen.
\textbf{ManPages:} \manpage {freqtweak} {1}
\textbf{Rpms:}
\beginsmallfont
\begin{description}
\item[\linkBaseAll{freqtweak}{\freqtweakver}]
\item[\linkDebugAll{freqtweak}{\freqtweakver}]
\item[\linkSourceAll{freqtweak}{\freqtweakver}]
\end{description}
\endsmallfont
_______________________________________________
PlanetCCRMA mailing list
PlanetCCRMA@ccrma.stanford.edu</FONT>
<A HREF="http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma"><U>http://ccrma-mail.stanford.edu/mailman/listinfo/planetccrma</U></A>
<FONT COLOR="#737373"></I></FONT></PRE>
</BLOCKQUOTE>
</BODY>
</HTML>
--=-EJWonq2KxRUb6vNN0KVv--