Monkey documentation in other languages
Monkey Forums/Monkey Programming/Monkey documentation in other languages
| ||
| Has anybody considered a way to adapt current makedocs utility so it can produce documentation in the OS installed language, if available? I would love to translate all Monkey documentation to Spanish, including official modules, if there's a built-in way to do it. Maybe an option to add the typicial en_EN, es_ES folders inside the monkeydocs folders with version on different languages? It does not seems like something very complicated to do. The problem is that non of the modules (AFAIK) support a way to read the locale information of the device... ? Any ideas? Maybe someone could do a German, French, Italic translations, etc. It would be something very nice to have and something that could be maintained by the community. |
| ||
| Here's my idea on how this could be done. Ted is modified to include an option to download a language pack for the correct version of Monkey-X that could be stored on a server. There should be nothing to stop Ted from being modified to a multi-language application. Qt should have a method of determining what language is installed on a system; this is used to select the correct language pack, while Ted supplies the Monkey-X version. makedocs could be modified to accept an additional parameter to select the directory to use for a language, but the output is always exported to the same directory. I think that the biggest task would be translating the monkeydoc files and modifying the html templates; documentation in modules would still be a problem. |
| ||
| While the idea is quite good, in my hones opinion, I think it would be slightly better if the language files are included as part of the monkeydoc folders, so any module developer can also provide language files for their modules and, all in all, could be done multilingual if makedocs is the tool that determines host os locales. something like monkeydoc.it_IT folder for italian documents, monkeydoc.es_ES for Spanish documents, etc. |
| ||
| @Ziggy: I think I know what you mean. That each .monkeydoc file has extra language extension appended to the name, then if the system locale matches, that monkeydoc file will used. A rough directory layout ->monkeydoc ---------------->blogsmodule.monkeydoc ---------------->blogsmodule.monkeydoc.es_ES (detected two blogsmodule.mokeydoc files use the locale to decide which to use) ---------------->mymodule.monkeydoc (no other detected so ignore locale and use this) makedocs could be modified to accept an additional parameter to select the directory to use for a language, but the output is always exported to the same directory. I think that I should have phrased that better. makedocs could be modified to accept an additional parameter to select a directory named e.g. es_ES (for Spanish) etc within any directory named monkeydocs. Then all you need to do is give it the general name of a locale and let makedocs do the rest. Edit: No matter if you use file extension or directories, you still have to handle those modules that have no documentation in the current system locale. |
| ||
| Yes, a fallback to non localized should use regular English, with non additional sufixes on filenames or folder names, shouldn't it? |
| ||
| no offence but unless their generation can be automated I highly doubt mark's going to do anything like this, its hard enough trying to get him to expand and fill out the docs we have never mind creating whole new sets in other languages. It's one of the many many things that would be good "IF" mark had the man power, but sadly will probably never come to pass. |
| ||
| @Paul: I don't think that there is a tool that can do any translation into another language with accuracy, so automation would be out of the question in any account. As I see it, it would be doable as long as there is someone willing to do the translations by hand and the makedocs program has the ability to distinguish the difference between the different locales (this being the key), then the foreign language maintainer could use diff to compare the old English docs with the new English version, and make the necessary changes to the foreign language monkeydoc file(s) in question, with minimal effort. The big task would be converting the current document files. Of course the weak link in this chain would be the foreign document maintainer. |
| ||
| Why shuld he do it? It's not that complicated to commit to github |
   |