On 17/10/2006, at 10:46 PM, A. Pagaltzis wrote:
I think it is a good idea to also include the translated text of each article, comment, etc. Eg. if they’re written in Markdown, they should be accompanied by an HTML version, so that when migrating to an engine which does not have Markdown support, such articles and comments are not lost.
Aside from the implementation issues I am unconvinced that this is a good idea in the first place.
If we have two alternative representations for an entry in the export file, it forces the importer *code* to choose which representation is the best match for the target blogging engine. It is not obvious to me that the code will always be able to make this decision in the best manner. Also, it's not obvious whether or not the redundant ("cooked") HTML representation will be "good enough". This content negotiation has the potential to significantly complicate the job of the importer.
I thought it might be simpler for the *exporter* to choose a content syntax - perhaps with the help of the user - which is deemed to be the most interoperable, and yet closest to the original.
For example, a Typo implementation would probably export in the source Textile/Markdown/whatever, and yet expand all the macros because these are by definition not interoperable. And yet if the user is exporting from one Typo installation to another, they probably don't want to expand these macros, so the decision probably needs to be under user control.
My assumption here is that the user prettymuch always knows what is the right level of translation to be done on the data when moving their data from one system to another. This may well be an incorrect assumption.
Even in the worst case, namely the user has authored their data in a format that is just not supported at all on the target platform, should it necessarily be the exporter that resolves this problem? It could be an *intermediate* tool that converts the content from one format to another, on behalf of the target platform. For example, a tool that renders all Markdown-formatted content into HTML would be very simple to write and would also achieve the required goal.
So despite all the above I'm not totally *against* the idea of supplying multiple representations in the export file, but I do think
there are alternatives which should be considered.
