There are more drawbacks :
- Need for manual action to rebuild the localized documentation
- Need for translation specific tooling to regenerate documentation
With the system I suggest, the documentation for locales is rebuilt automatically when you build the master documentation, without requiring any extra action or tools. I'm ok with requiring tools for translators, but if maintaining a documentation need extra-care for the developers, it will sooner or later go out of date without notice.
I agree I did not document myself enough about existing translation tools before writing this pre-RFC. For translators, having the ability to use existing translation tools might be useful. I read the documentation about ".po" and it seems that supporting translation tools would not change much what I am proposing. You need a tool to generate them from data extracted from the the master, and since the purpose of rustdoc is extracting the documentation from the source, it is the best tool to do that. It would be just need to generate ".po" files instead of the ".loc" format I proposed. The example file in my proposal would turn to :
msgid ""
msgstr ""
"Project-Id-Version: crate_name\n"
"PO-Revision-Date: 2016-03-04 15:13+0200\n"
"Last-Translator: John Doe <john.doe@domain.net>\n"
msgctx "struct Mainstruct"
msgid "The main struct of the library, it is very important"
msgstr "La struct principale de la bibliothèque, Elle est très importante"
msgctx "impl Mainstruct > fn do_something"
msgid "Do something interesting"
msgstr "Fait quelquechose d'intéressant"
And on updated texts, we would get:
#, fuzzy
#| msgid "Old main language text"
msgctx "impl Mainstruct > fn do_something"
msgid "New language text"
msgstr "Translation"