Optional note for pending scientific verification

[nditada]

We should have a separate .md file that can be displayed on the top of the translated Act & Prepare page that reads "This translation has not yet been verified by a scientist, if you can help please register here".

That will allow to get translations out of the door when they are ready, and increase the chances of finding a person that can verify the accuracy.

And then we can simply turn it off when that happens.

[emersonthis]

@nditada Is this deliverable here for translators to provide the 7 different translations of:

This translation has not yet been verified by a scientist, if you can help please register here.

Or is there engineering effort here too? Is the idea for the message to appear/disappear automatically? And what is the scope of the warning? Is it one message for the entire page? Or do we apply the disclaimer selectively to the individual entries?

[rousik]

Maybe this has been discussed but I was wondering what is the scope of the scientific validation/endorsement?

As we keep on updating translation to keep pace with rapidly changing original content, how do we re-verify that the changes are still "good" and we are not introducing information that is not approved? If we decide that scientific review is bound to a specific revision, how do we ensure that sci-reviewers only need to check on what has changed since the last time instead of having to check the entirety of the web site.

[rousik]

Once we agree on the procedure I think I can tackle the technical component of this.

[matiasgarciaisaia]

@emersonthis I guess the idea of having that notice as a separate file is for translators to be able to translate it with the rest of the site - and decide at build time whether to include that notice or not.

@rousik the idea is that, under normal circumstances, every new published version of the site has scientific validation - so no need for the notice here.

But there are cases in which we don't have enough scientific volunteers to keep up with the reviews. In those cases, we may want to send special deploys that are not verified, and thus include this notices.

[matiasgarciaisaia]

So probably two different workflows, or have any way of parameterising if the build show include the notice or not.

[rousik]

Also see related conversation here: https://github.com/flattenthecurve/guide/issues/295

Would it help to keep list of primary contacts and/or scientific reviewers for specific languages? Language owners would help when we need to update the contents (e.g. when design has changed and resulted in style discrepancies in translations) while sci-reviewers would be helpful to approve PRs when new language content is about to go out.

It seems to me that for languages where there's sci-reviewer scarcity, we can either keep the banner until we have someone "sign off" and then reset back to "not-reviewed" when we merge new content?

The list of owners/reviewers may also be a place where we indicate how do we approach each language (need/want sci review or prefer to roll out new content with banner and get review afterwards).

What do you think?

On Mon, Apr 6, 2020 at 9:27 PM Matías García Isaía notifications@github.com wrote:

So probably two different workflows, or have any way of parameterising if the build show include the notice or not.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/flattenthecurve/guide/issues/318#issuecomment-610152717, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYSCGA7UK4HIZL6BV5YRD3RLKMT7ANCNFSM4MCVNP3A .

[emersonthis]

How about a field I the yaml header that we use as a flag to turn the notice on or off? The a localized include for each language version of yur component?

On Apr 6, 2020, at 9:40 PM, Jan Rous notifications@github.com wrote:

 Also see related conversation here: https://github.com/flattenthecurve/guide/issues/295

Would it help to keep list of primary contacts and/or scientific reviewers for specific languages? Language owners would help when we need to update the contents (e.g. when design has changed and resulted in style discrepancies in translations) while sci-reviewers would be helpful to approve PRs when new language content is about to go out.

It seems to me that for languages where there's sci-reviewer scarcity, we can either keep the banner until we have someone "sign off" and then reset back to "not-reviewed" when we merge new content?

The list of owners/reviewers may also be a place where we indicate how do we approach each language (need/want sci review or prefer to roll out new content with banner and get review afterwards).

What do you think?

On Mon, Apr 6, 2020 at 9:27 PM Matías García Isaía notifications@github.com wrote:

So probably two different workflows, or have any way of parameterising if the build show include the notice or not.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/flattenthecurve/guide/issues/318#issuecomment-610152717, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYSCGA7UK4HIZL6BV5YRD3RLKMT7ANCNFSM4MCVNP3A .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[kendrahavens]

Hi there, I'm new here. :) Feel free to disregard if this was not the direction you wanted. I was mocking up the simplest solution while familiarizing myself a bit with the code base.

In my PR, by simply adding the include disclaimer below to any post in act_and_prepare

{:.disclaimer}
{% include disclaimer/en/disclaimer.md %}

The following notes can appear:

1. Needs scientific review note at the top of the page

2. Needs scientific review note individual sections (posts)

It does not address all the concerns mentioned here and users would need to manually manage adding or removing the {include} tag on a per post/page basis. If this is a good solution, the "disclaimer.md" files I've added would need to be translated to the target languages.

[rousik]

Someone might need to confirm that this is indeed true but my understanding is that sci-review should apply to the entire content release and not to individual blocks of text. This may take a little more time per individual review but it should be much simpler to deal with operationally. I do like the disclaimer.md approach and we can probably include this automatically depending on the value of language-specific flag.

On Wed, Apr 15, 2020 at 12:38 AM Kendra Havens notifications@github.com wrote:

Hi there, I'm new here. :) Feel free to disregard if this was not the direction you wanted. I was mocking up the simplest solution while familiarizing myself a bit with the code base.

In my PR, by simply adding the include disclaimer below to any post in act_and_prepare

{:.disclaimer} {% include disclaimer/en/disclaimer.md %}

The following notes can appear:

1.

Needs scientific review note at the top of the page [image: image] https://user-images.githubusercontent.com/8293542/79302756-17f5ae00-7ea2-11ea-8990-ee1d3ecfb8e8.png 2.

Needs scientific review note individual sections (posts) [image: image] https://user-images.githubusercontent.com/8293542/79302925-7cb10880-7ea2-11ea-894c-e9f9ff01a4c2.png

It does not address all the concerns mentioned here and users would need to manually manage adding or removing the {include} tag on a per post/page basis. If this is a good solution, the "disclaimer.md" files I've added would need to be translated to the target languages.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/flattenthecurve/guide/issues/318#issuecomment-613846734, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABYSCGGFE46NXHEH2IPJBBDRMVI7JANCNFSM4MCVNP3A .

[rousik]

After digging deeper into Lokalise/scientific verification process I can see that each key gets reviewed separately, hence adding the sci-review notice to each piece of text that has not been reviewed might be the right way to go about it. I would still try to see if we can pull the review-status of each piece of text into the md files instead of manually keeping this fragment in the translation and integrating the addition/removal of it into the translation/sci-review processes that are currently in place.

Let me take a look at whether this would be feasible.

[nditada]

adding the sci-review notice to each piece of text that has not been reviewed might be the right way to go about it.

That would be a super plus, but not a Must Have.

[rousik]

After investigating Lokalise API I have discovered that we can pull different sets of strings using the filter_data flag. The relevant options are:

1. no restrictions. This pulls the most recent translation of every key. This is what the script does by default now.
2. reviewed. Pulls only keys where the latest version is also marked as reviewed.
3. last_reviewed_only: for each key, the latest version that is marked as reviewed is fetched.

(3) will result in pulling whatever has the review and may pull data that is outdated. (2) will skip over records where there are newer translations that are not marked as reviewed.

Right now I'm exploring a process where we would pull everything from Lokalise (request of type 1) and pull the review status of these (request of type 2) and automatically insert the disclaimer notice into md files where the translation key was not present in the review status request.

[nditada]

That sounds like a super smart approach @rousik!

[rousik]

https://github.com/flattenthecurve/guide/pull/357 changes import_translations.rb script to allow this. The functionality is flag-controlled and disabled by default.

[rousik]

The script is submitted but the new behavior is off by default. I want to safely roll out to live languages and then enable by default. So there is still some work to do on this

[rousik]

Another PR improving how the notices are included is in flight, see #381. Notices will show up as soon as we 1. enable them by default or enable them for individual languages and 2. reimport the most recent translations for given language (which should trigger the inclusion of the notice).

The outstanding question is whether we should also show the notice on the COVID-19 page. My take is that we absolutely should. The question remains as to whether we should add it to the page as a whole or still keep it attached to each section.

This means that pages that do not have reviewers will be plastered with these notices but I suppose this is "by design".