Hi, Frank, Martin, Ain, and other translators,
Providing automated cleanup tools is one of the things I enjoy doing for
the Documentation Project. The major tool I use is Writer: people tend
to forget that our flagship word processor is a fine and powerful text
editor, too. Add a little bit -- or a lot -- of Basic code, and one can
accomplish almost anything, with text documents. And, by definition, it
runs on any supported platform.
Writer handles XML, and HTML 3.2 Help files, just fine, as ordinary
text. It's not as pretty, for humans, as specialized editors would be,
but Basic doesn't care.
Specifically, getting rid of the 6-blanks strings in the CWS should be
easy, assuming that there are no legitimate instances of such a thing.
If the files are (or can be) laid out in a hierarchical set of
directories, the way the Help files are when a source tar-ball is
unpacked, then I can scan all the files in one operation, processing
each one, and save the output in place, or to a parallel set of directories.
Assisting the translators directly is more difficult, hampered by my
massive ignorance of their procedures.
Do I have the big picture right? We have three file-sets, let's call them:
* m51_en which has two descendants,
** m51_XX with the same structure, but translated content, and
** m57_en with additions, deletions, and changes to both structure and
content.
The mission is to unite these two descendants, with midwifery by the
translator, to produce m57_XX, where "XX" is an ISO language code.
Ideally, by running a specialized type of diff on m51_en and m57_en, I
should be able to produce an updated m51_XX:
* structure-only changes applied (anything only affecting tags).
* deleted lines removed.
* text additions and changes inserted, marked with some kind of sentinel
(like ยงยง or such), for human attention.
How well I can do that is open to question. It would be much easier if
every translator has all three file-sets locally available.
The tool should be equally useful for future releases, as well.
If anyone is interested in this approach, please let me know (on
dev-doc). --/tj/
--
T. J. Frazier
Melbourne, FL
(TJFrazier on OO.o)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@documentation.openoffice.org
For additional commands, e-mail: dev-h...@documentation.openoffice.org
