Rendering on read.bibletranslationtools.org #1

Open
opened 2019-11-01 19:48:51 +00:00 by chrisjarka · 5 comments
Owner

We have noticed that the rendering of the WACS English Translation Notes is not working on the read.btt.org site.

http://read.bibletranslationtools.org/u/WycliffeAssociates/en_tn/b994ee996d/

While the DCS English Translation Notes is rendering:

https://door43.org/u/WycliffeAssociates/en_tn/0c84896af2/

The read.btt.org site has this warning (even though the message is 'success):

  • psa/124/005.md: contains invalid link: (..124/002.md)

  • psa/124/004.md: contains invalid link: (..124/002.md)

  • Linting process ended abnormally: An error occurred (ResourceNotFoundException) when calling the Invoke operation: Function not found: arn:aws:lambda:us-west-2:581647696645:function:prod-tx_markdown_linter

  • Linter failed for identifier:
    baf2a23b876bdd896432bef9c587e10e80d39c595a77afe2c4a4454576eb6852/66/13/19-PSA.md

We have noticed that the rendering of the WACS English Translation Notes is not working on the read.btt.org site. http://read.bibletranslationtools.org/u/WycliffeAssociates/en_tn/b994ee996d/ While the DCS English Translation Notes is rendering: https://door43.org/u/WycliffeAssociates/en_tn/0c84896af2/ The read.btt.org site has this warning (even though the message is 'success): * psa/124/005.md: contains invalid link: (..124/002.md) * psa/124/004.md: contains invalid link: (..124/002.md) * Linting process ended abnormally: An error occurred (ResourceNotFoundException) when calling the Invoke operation: Function not found: arn:aws:lambda:us-west-2:581647696645:function:prod-tx_markdown_linter * Linter failed for identifier: baf2a23b876bdd896432bef9c587e10e80d39c595a77afe2c4a4454576eb6852/66/13/19-PSA.md
craig was assigned by chrisjarka 2019-11-01 19:48:58 +00:00
Author
Owner

The Notes are rendering on bibletranslationtools.org but there are 61 PAGES of errors in the report. Mostly about headers.
https://wycliffeassociatesinc-my.sharepoint.com/🅱️/g/personal/christine_jarka_wycliffeassociates_org/Ef-xQAWq7ilNq5V90bMkdroB87oTE8m6jDDN7161315RRA?e=wHfpLG

The Notes are rendering on bibletranslationtools.org but there are 61 PAGES of errors in the report. Mostly about headers. https://wycliffeassociatesinc-my.sharepoint.com/:b:/g/personal/christine_jarka_wycliffeassociates_org/Ef-xQAWq7ilNq5V90bMkdroB87oTE8m6jDDN7161315RRA?e=wHfpLG
Owner

From Craig's email Dec 2, 2020
Regarding #1, the recent update to the rendering pipeline should have fixed the issue -- I believe en_tn is rendering now.


The 4 and 5 hashmark headings in en_tn are not rendering right in the "See in Reader" view.

For example, one of the errors in the document Chris posted above was on en_tn/2th/01/intro.md
https://content.bibletranslationtools.org/WycliffeAssociates/en_tn/src/branch/master/2th/01/intro.md

The headings Structure and formatting and Other possible translation difficulties in this chapter start with four hashmarks. In "See in Reader" those headings are too small.

The heading Paradox has 5 hashmarks. In "See in Reader," it is too small, and one hash mark shows.

4 hash marks 4959 times (I think this may include those with 5 hashmarks.)
5 hash marks - 2032 times


How 4 hash marks in other resources show up in "See in Reader" view:
TM: 275 times (48 of these are in archive) Looks good in "See in Reader"
BC: 229 times - No "See in Reader" view.
TQ: None
TW: None
GWT: None

How 5 hash marks in other resources show up in "See in Reader" view:
TM: 2 times. Only in figs-metaphor/01.md/. Looks like ordinary paragraph text.
BC: 5 times No "See in Reader" view.


I'm surprised that the 4 hashmarks render differently in tN and tM. Can we have different rules in different resources for how a certain number of hashmarks renders in "See in Reader"? If so, I guess we don't have to worry about changes in one resource affecting another resource.

  • Could the rendering of all the hashmark headings look like the rendering on WACS?
  • Could the renderer be changed to accept headings that increment by more than one level at a time without calling it an error?
  • Could the renderer be changed to accept headers that are not followed by a blank line without calling it an error?

Hopefully we'll get to talk about this next week.

From Craig's email Dec 2, 2020 Regarding #1, the recent update to the rendering pipeline should have fixed the issue -- I believe en_tn is rendering now. ----------- The 4 and 5 hashmark headings in en_tn are not rendering right in the "See in Reader" view. For example, one of the errors in the document Chris posted above was on en_tn/2th/01/intro.md https://content.bibletranslationtools.org/WycliffeAssociates/en_tn/src/branch/master/2th/01/intro.md The headings **Structure and formatting** and **Other possible translation difficulties in this chapter** start with four hashmarks. In "See in Reader" those headings are too small. The heading **Paradox** has 5 hashmarks. In "See in Reader," it is too small, and one hash mark shows. 4 hash marks 4959 times (I think this may include those with 5 hashmarks.) 5 hash marks - 2032 times --------- **How 4 hash marks in other resources show up in "See in Reader" view:** TM: 275 times (48 of these are in archive) Looks good in "See in Reader" BC: 229 times - No "See in Reader" view. TQ: None TW: None GWT: None **How 5 hash marks in other resources show up in "See in Reader" view:** TM: 2 times. Only in figs-metaphor/01.md/. Looks like ordinary paragraph text. BC: 5 times No "See in Reader" view. --------- I'm surprised that the 4 hashmarks render differently in tN and tM. Can we have different rules in different resources for how a certain number of hashmarks renders in "See in Reader"? If so, I guess we don't have to worry about changes in one resource affecting another resource. * Could the rendering of all the hashmark headings look like the rendering on WACS? * Could the renderer be changed to accept headings that increment by more than one level at a time without calling it an error? * Could the renderer be changed to accept headers that are not followed by a blank line without calling it an error? Hopefully we'll get to talk about this next week.
SusanQuigley added the
Chris J
label 2020-12-04 23:00:43 +00:00
Owner

TN
Change #### to ###.
Change ##### to ####.

See how it looks in See on Reader.

**TN** Change #### to ###. Change ##### to ####. See how it looks in See on Reader.
Owner

John made the changes. The Read on Web view is still updating, so we don't know how it looks.

Dec 14. The Read on Web view is still updating. WA_IT helpdesk [Ticket #42763]

John made the changes. The Read on Web view is still updating, so we don't know how it looks. Dec 14. The Read on Web view is still updating. WA_IT helpdesk [Ticket #42763]
SusanQuigley removed the
Chris J
label 2020-12-12 00:00:09 +00:00
Owner

1/11/21 The section headings and sub-section headings in the book and chapter introductions are too small.

(#) Used for title of page and for snippets.
(##) Used for "Part" headings in book intros and the heading "Links" at the bottom of the intro pages.
(###) Used for section headings.
(####) Used for sub-section headings.

(###) appears to be the same size as the normal paragraph font.
(####) shows up as smaller than the normal paragraph font.

Request:
Could all of the headings to be larger than paragraph font, with (####) being the smallest heading and # being the largest (or if we also use bold, then the smallest heading could be the same size as paragraph font)?


1/12/2021: I'm testing hashmarks in Translation Notes Gen 1 intro.
I changed them so there are only #, ##, and ###.
I want to see how this looks in Read on Web and PDF.
We may not need #### in tN.

This looks pretty good on Read on Web.
(###) is now the same size as the paragraph font. It may need to be bigger or bold.
(##) is now bigger than (###)

I'm waiting for pdf to update. It still says "Contains revisions as of: 2020-12-15."

Translation Words.
It looks like all topics start with #.
It looks like all topics have ##.
believe.md is the only topic with ###. See tW issue 59. Check pdf and Read on Web.
en_tw/LICENSE.md also has ###.

Translation manual.
Most topics have only ### or #### or both.
en_tm/markdownformat.md has #, ##, ###, and ####.
The front and back matter starting with 00-tM_front&back have # and ##.
en_tm/translate/tA Decisions.md has ### and #####, but it's only for our use.

1/11/21 The section headings and sub-section headings in the book and chapter introductions are too small. (#) Used for title of page and for snippets. (##) Used for "Part" headings in book intros and the heading "Links" at the bottom of the intro pages. (###) Used for section headings. (####) Used for sub-section headings. (###) appears to be the same size as the normal paragraph font. (####) shows up as smaller than the normal paragraph font. Request: Could all of the headings to be larger than paragraph font, with (####) being the smallest heading and # being the largest (or if we also use bold, then the smallest heading could be the same size as paragraph font)? ------------- 1/12/2021: I'm testing hashmarks in **Translation Notes** Gen 1 intro. I changed them so there are only #, ##, and ###. I want to see how this looks in Read on Web and PDF. **We may not need #### in tN.** This looks pretty good on Read on Web. (###) is now the same size as the paragraph font. It may need to be bigger or bold. (##) is now bigger than (###) I'm waiting for pdf to update. It still says "Contains revisions as of: 2020-12-15." **Translation Words.** It looks like all topics start with #. It looks like all topics have ##. **believe.md** is the only topic with ###. See tW issue 59. Check pdf and Read on Web. en_tw/LICENSE.md also has ###. **Translation manual**. Most topics have only ### or #### or both. **en_tm/markdownformat.md** has #, ##, ###, and ####. The front and back matter starting with 00-tM_front&back have # and ##. en_tm/translate/tA Decisions.md has ### and #####, but it's only for our use.
Sign in to join this conversation.
No Milestone
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: WycliffeAssociates/en_tn#1
No description provided.