To do: whitelist additional keys for translation

[naturalshine]

What is the strategy for whitelisting additional keys in both the md-to-jsonKV and jsonKV-to-md process? I wasn't sure when/how to go through this... @jmatsushita, Would you like to review the existing front-matter first, or if there's a way for me to review its appropriateness?

Relevant to iilab/contentascode#3

[jmatsushita]

Hi! You can make a first pass at this with the simple rule "is it
translatable or localisable"?
On 16 Feb 2016 18:21, "cst" [email protected] wrote:

What is the strategy for whitelisting additional keys in both the
md-to-jsonKV and jsonKV-to-md process? I wasn't sure when/how to go through
this... @jmatsushita https://github.com/jmatsushita, Would you like to
review the existing front-matter first, or if there's a way for me to
review its appropriateness?

Relevant to iilab/contentascode#3
iilab/contentascode#3

—
Reply to this email directly or view it on GitHub
#28.

[naturalshine]

@jmatsushita Yep, sounds good! I'll start working on this now.

[naturalshine]

@jmatsushita I'm working through whitelisting keys on the tx_md2jsonKV initial conversion and running into greater complexity than we've dealt with before (as expected). I'm adapting the pre-tx-push.jq to bring in keys and subkeys dynamically. As part of this, I've realised that several of the files have multiple translatable fields within subkeys where this script only allows for the title fields within subkeys to be translated.

As an example, see the "item" and "description" fields in footer.md.

Currently, the "title" fields within each subkey are entered into JSON KV as FILENAME.MD---subkey---LINK or FILENAME.MD---subkey---STATUS or FILENAME.MD---subkey---ITERATOR. In the above example, if the script is modified to allow for several translatable fields within every subkey, "description" and "item" would end up with the same name: FILENAME.MD---subkey---LINK. Of course, an easy fix for this is to just add the name of the key to the end of JSON KV, such that FILENAME.MD---subkey---LINK---KEYNAME.

However, I want to raise this in relation to #26 . Thinking about creating a numeric indicator that is applied both in .json.orig and in .json.tmp (here, applying this key to our discussion of translation keys) would reduce potential complexity of json KV key names significantly. What do you think?

Relevant to iilab/contentascode#3

[jmatsushita]

I think it would be good to keep meaningful and readable intermediate key names that help us troubleshoot the pipeline, so I would add the name of the subkey at the end as well as a numeric indicator for the order. Can we make the separator just --- instead of ---subkey---?

[naturalshine]

Hey @jmatsushita ah I misread this the first time (hence the deleted comment). I think my terms are a bit confused, so I'm still a bit unclear on what you mean with the naming convention.. Could you give an example using this case? Current convention would have this as 0001-01-01-footer.md---footer---LINK, but here we have item and description that share the LINK.