It would be good to have a snify-like tool that
- is started on a top-level document
foo.en.tex with a language argument (e.g. de)
- includes all imported files (option)
- for every annotated symbol in the file sees if there is a
de translation for its module.
- if not, it generates a translation module stub
foo.de.tex with
...\begin{smodule}[sig=en]{foo}...\begin{sdefinition} <point of insertion here> \end{smodule}...- for every symbol
bar declared in foo.en.tex it adds a line \definiendum{bar}{XXXXX}
- and call the editor of choice (from the
EDITOR env var) on foo.de.tex, so that the author can either add a full translation or just the dictionary information by replacing the XXXXX.
The idea of a module stub is to have all the necessary de-verbalizations so that we can make a dictionary service in ALeA.
In the absence of a better naming Idea I would call it transify. Transy would have a UI like snify. In fact I guess most of the UI can directly be re-used.
Eventually, we could add various pre-translation functionalities, but currently the dictionary information would already help.
It would be good to have a
snify-like tool thatfoo.en.texwith a language argument (e.g.de)detranslation for its module.foo.de.texwith...\begin{smodule}[sig=en]{foo}...\begin{sdefinition} <point of insertion here> \end{smodule}...bardeclared infoo.en.texit adds a line\definiendum{bar}{XXXXX}EDITORenv var) onfoo.de.tex, so that the author can either add a full translation or just the dictionary information by replacing theXXXXX.The idea of a module stub is to have all the necessary
de-verbalizations so that we can make a dictionary service in ALeA.In the absence of a better naming Idea I would call it
transify. Transy would have a UI likesnify. In fact I guess most of the UI can directly be re-used.Eventually, we could add various pre-translation functionalities, but currently the dictionary information would already help.