This tool is super-easy to use in Eclipse IDE (Ant, Java).
It's a good start to have locale-specific strings like "Table of Contents", dates, abbreviations, etc. However, descriptions of jobs, experiences, diplomas, etc. won't be able to be translated in a standard way, so I think more support is needed to support a single CV that's output in various formats that involve languages.
I'm wondering if there's another approach, where locale-specific translations are stored inside of the XML elements. E.g., PositionHistory.Title.EN = "Director" (for the English version of the Title) and PositionHistory.Title.FR = "Directeur" (for the French version), etc. Maintaining a CV in this manner is much easier, I think. I realize my XML syntax is not standard, but I think you can get the idea. There are actually multiple strings stored in each element, but they have an attribute (or whatever it's called in XML) for the language.
How hard would it be to have the language code defined in the parameters.xsl file work to pull out the language-defined strings in the various XML elements in this way? I'd be willing to help test this, as I'm looking for a solution to updating my 5+ formats of my CV (at least 4 in French, one in English). A lot of academics would have the same issue, and could benefit from this. We've already talked about it on Stack Exchange.
I would probably implement this as a separate preprocessing step that does the language translations as you suggest. The multiple translated XML documents would then be fed through HR-XSL as usual.
Thanks for your interest in the tool, but I no longer have the time or desire to add to this project. I'd be happy to hand the reins to someone else.
Thanks for the reply. I'll see if I can find a senior project student to contribute to this.
Otherwise, regarding the internationalization angle, I once did some web pages that had DIV tags for the different languages. The CSS was used to hide (DISPLAY=NONE or something) the content of the language NOT selected in the output. Would this strategy work also to generate PDF/TEXT through DOCBOOK? Sorry for the ignorance on my part about those techs.
I would probably try to do it as an XML-to-XML translation using XSLT. You would start with an HR-XML document containing the locale-independent elements. The XSLT would then translate this to another HR-XML document with those elements replaced by their locale-specific translations. (Run the translation multiple times and generate multiple documents for each locale as necessary.) When that's done you can run the result(s) through HR-XSL. That way you never have to modify HR-XSL. The steps in the pipeline are entirely self-contained.
Log in to post a comment.