@harjot1singh we need to discuss the vastly same data sources (aside from minor spelling disparities) it's mostly just vishram placements. could we have a "variants" section that primary sources reference? something like the following:
[[content]]
source = "SDGR"
type = "meta"
page = 7
line = 4
data = [
"ਕਿ ਸਰਬੱਤ੍ਰ ਜਾਪਿਯੈ ॥",
"ਕਿ, ਸਰਬਤ੍ਰ ਜਾਪਯੈ ॥",
]
[[content]]
asset = "DGDG"
type = "primary"
data = 1
[[content]]
asset = "DDTK"
type = "primary"
data = 2
[[content]]
asset = "DSKO"
type = "translation"
language = "en"
data = "That Thou art remembered everywhere!"
[[content]]
asset = "RSJD"
type = "translation"
language = "pa"
data = "ਤੂੰ ਸਭ ਥਾਂਵਾਂ ਤੇ ਜਪਿਆ ਜਾਂਦਾ ਹੈਂ,"
TOML has ordered arrays and doesn't care about indents or whitespace and encourages trailing commas. If we keep adding sources and they all look largely the same, this will save us a lot of space. Can also do something like ignoring vishraman in the primary (but that would be more annoying to dictate on each primary type imo).
Edit: There should be some bot that checks PRs to make sure no one enters a variant in the middle (and that they're always appended to the last of a list), as well as to make sure that all variants are unique.
Edit 2: It also makes sense to have a bot make sure that all primary types are at the top (below the first block for variants)
Edit 3: It could be named "meta", as the page/line info is also supposed to be per asset/PDF. So if the meta section existed, it would place the "page/line" in whatever the chosen "standard" is (for example to reference SGGS ji saroops). I've updated my toml exaple above to match that. This way a primary type can use page/line of the actual PDF/files that it's showing in physical format. And we can use it for bound box to highlight files exactly where the line is.
Originally posted by @bhajneet in #1920 (review)
Edit 4: In addition, we should make sure that all data variants are being used! LOL so that yes, each asset will be tied to a primary data value. But the meta "source" will be able to contain all the variants. This might also have unexpected benefits in search/querying for lines?
@harjot1singh we need to discuss the vastly same data sources (aside from minor spelling disparities) it's mostly just vishram placements. could we have a "variants" section that primary sources reference? something like the following:
TOML has ordered arrays and doesn't care about indents or whitespace and encourages trailing commas. If we keep adding sources and they all look largely the same, this will save us a lot of space. Can also do something like ignoring vishraman in the primary (but that would be more annoying to dictate on each primary type imo).
Edit: There should be some bot that checks PRs to make sure no one enters a variant in the middle (and that they're always appended to the last of a list), as well as to make sure that all variants are unique.
Edit 2: It also makes sense to have a bot make sure that all primary types are at the top (below the first block for variants)
Edit 3: It could be named "meta", as the page/line info is also supposed to be per asset/PDF. So if the meta section existed, it would place the "page/line" in whatever the chosen "standard" is (for example to reference SGGS ji saroops). I've updated my toml exaple above to match that. This way a primary type can use page/line of the actual PDF/files that it's showing in physical format. And we can use it for bound box to highlight files exactly where the line is.
Originally posted by @bhajneet in #1920 (review)
Edit 4: In addition, we should make sure that all data variants are being used! LOL so that yes, each asset will be tied to a primary data value. But the meta "source" will be able to contain all the variants. This might also have unexpected benefits in search/querying for lines?