-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Transifex jsonKV -> markdown conversion: Order of Yaml front matter #26
Comments
It shouldn't matter but I'd like us to preserve the original order if
|
@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. |
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. |
Works for me. |
…ment for retaining correct order on reassembly PanicInitiative#28 PanicInitiative#26 iilab/contentascode#3
…updates to tx_jsonKV2md.py and tx_md2jsonKV.py and corresponding files for PanicInitiative#28. YAML keys need to be removed but YAML frontmatter is now ordered for PanicInitiative#26. Relevant to iilab/contentascode#3
…, closing issues PanicInitiative#26 and PanicInitiative#28 . Relevant to iilab/contentascode#3
…x_jsonKV2md.py PanicInitiative#26 PanicInitiative#28 illab/contentascode#3
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
The text was updated successfully, but these errors were encountered: