Work on the v2 of Bilara is proceeding well, and we hope to have a working version by, say end of January.
Meanwhile, the work exposed a weakness of the current bilara-data specification, namely that we permit omitted segment IDs. This makes it harder to keep the different files in sync.
So the new requirement is that:
All versions of the same text must have the full set of segment IDs.
This is currently permitted but not required. The change will make it required.
Since this is simply a subset of what is already allowable, we do not expect any problems upgrading data. Nonetheless, we should do so cautiously and give developers time to test downstream applications, including:
SC
Bilara
Github actions
Publishing
Voice
anything else?
After discussion with the STXnext team, I propose we make the change like this.
stxnext
Bilara v2 is developed using the new specification.
STXnext devs are responsible for scripting the adaptation of the new spec.
The data in Bilara v2 dev is forked and therefore stale. STXnext devs will update any data before pushing to bilara-data.
SC devs testing
Meanwhile, we will push one file in the next spec to bilara-data/published
say, dn1
Developers test applications.
Push a collection to bilara-data/published.
say, mn-mulapariyayavagga
Developers test applications.
rollout
This will bring us to say mid-Jan. Let us accept Bilara v2 as ready for production when it is stable and has feature parity with old Bilara, i.e. it does not need to be feature complete, just usable.
When ready for rollout, we inform all devs and bilara users. sujato
Roll out Bilara v2 on a Monday. stxnext
Pause all use of Bilara for at least 48 hours. sujato
Upgrade bilara-data both unpublished and published to new spec. This pushes the new data spec to production. stxnext
So for the internationalization files currently they can include just some of the key value pairs. But after this they will require all key/values with blank values for all yet untranslated segments? And do I understand that step 4 is going to take care of doing that?
That’s correct, every version of the same file—whether it is different translations, markup, refer4ences, anything at all—will have the exact same set of keys, and null values for empty segments.
Indeed, our fine friends at STXnext will do all this, we just have to test it.
I doubt it. As it is I’m always expecting to have empty segments. And I think I often go off of the keys of the English rather than the array of ordered segment names. Which is probably a bad idea.
In any case most of my apps reuse the same basic code so it shouldn’t be too hard to fix. (I know, famous last words) I might even get motivated to actually make it actual reused code in case something like this comes up again. It’s good for me to revisit the code from time to time anyway.
Most of the missing segments are probably in the variation and other offset files, eh? So far I don’t think I’m using them.
I think Voice apps will be fine. We have code that merges non-aligned segments. After the upgrade, we could delete that code for performance improvements.
Bhante @Sujato, I’m wondering if in Bilara v2 translators will be notified if a root segment they have translated changes.
We recently had the case where there was a typo in an English interface segment. I had to go back and manually notify translators of the change. Of course if the work was done outside of Bilara there’s nothing to be done. However it would be great for them to be notified, since editing root segments is one of the new features (as I understand it).
Let me know if you want me to write up an issue. I also realize it may be too late for this.
There is an issue for notification about changes in an existing translation on which a translator relies, but I am not sure about changes in the root text. These happen less often obviously, but they do happen. (Entire roadmap here.)
