Transifex jsonKV -> markdown conversion: Order of Yaml front matter

[naturalshine]

Hi @jmatsushita! Am I correct in thinking that order of yaml front matter doesn't matter? Because we're dealing with python dictionaries (unordered) for all of the json handling, it's impossible to give keys an order other than alphabetical. Does this matter? If yes, it's possible to reorder yaml frontmatter in source .md files to have alphabetically-ordered keys -- or find another solution?
In the fringe cases in which an iterator provides the final "key" in the Transifex JSON KV-pair key name, it's possible to reorder without alphabetization because of this key. Relevant to iilab/contentascode#3

[jmatsushita]

It shouldn't matter but I'd like us to preserve the original order if possible to avoid confusing the original authors. We might also want to try to avoid arrays by generating a key as we've discussed. Otherwise I'm afraid we might have to move to an ordered list... Unless you can think of something else? On 16 Feb 2016 18:15, "cst" notifications@github.com wrote:

Hi @jmatsushita https://github.com/jmatsushita! Am I correct in thinking that order of yaml front matter doesn't matter? Because we're dealing with python dictionaries (unordered) for all of the json handling, it's impossible to give keys an order other than alphabetical. Does this matter? If yes, it's possible to reorder yaml frontmatter in source .md files to have alphabetically-ordered keys -- or find another solution?

In the fringe cases https://raw.githubusercontent.com/PanicInitiative/panicbutton.io/contentascode/_posts/mobile/0001-01-01-checklist.md in which an iterator provides the final "key" in the Transifex JSON KV-pair key name, it's possible to reorder without alphabetization because of this key. Relevant to iilab/contentascode#3 https://github.com/iilab/contentascode/issues/3

— Reply to this email directly or view it on GitHub https://github.com/PanicInitiative/panicbutton.io/issues/26.

[naturalshine]

@jmatsushita, hi! I'm looking at the order of all the files more closely now, and this is an issue from the very beginning of the tx_md2jsonKV translation process -- the first .json.orig files generated already have the yaml front-matter out of order. To be clear, this applies to all contents of the front-matter, not just what goes into translation and comes back. My first instinct would be to add order-specific numbering to each of the yaml front-matter terms (e.g. K01-term) upon insertion into the json.orig file.

These newly named keys in .json.orig would not be carried through the transifex process (not that it would matter if they were, I guess), because new json KV files are generated from yaml to create the .json.tmp series -- it's a distinct process separate from the creation of .json.orig.

When the translated json KV file is returned, and run through tx_jsonKV2md, .json.orig forms the base for the final dictionary of values. Thus, the numeric indicators can be used to order the final yaml by simply sorting the final dict by key alphabetically. The K## values can be sliced off of the yaml front-matter terms when writing the final md file .

Does that sound overly complicated? Ordered lists are also possible, though I really prefer dictionaries for this kind of work in python. They would need to be employed, at minimum, in the creation of .json.orig during tx_md2jsonKV and in the fetching of .json.orig in tx_jsonKV2md, but at first pass through this, it seems like everything else could probably remain in dictionary form.

[naturalshine]

Ah, and what I meant to mention -- I think the adding of numeric indicators that I suggest above is slightly different than the assignment of keys that we talked about, as it deals with all of the yaml front-matter items and not just the translatable ones.

This numeric indicator approach seems simpler to me than the key-addition process we were discussing and solves a different problem, but it would also, of course, be possible to mod this solution to solve the translatable-item-key issue.

[jmatsushita]

Works for me.