From @paul2keller:

In less wide browser windows the grey background disappears on the left and the right (see below) . As a result the visual effect (a sheet of paper on top of something) disappears. The grey background should remain visible (until we reach a very narrow window width the version for mobile phones does not have to have this effect)

Reported by @paul2keller:

Overall the text sizes are too big (for my taste) and should be reduced. I would settle for something that is 85-90% of the current text sizes. (with the exception of the text size in the navigation bar which is fine as it is)

The font weight of H2 looks to heavy (if you compare it to the mockup done by Ryan (see below). I would suggest that we make it a little bit lighter.

Reduce the overall width of all body text by 10-15% to make text easier to read.

This is the related issue previously mentioned to @literarymachine and @ryanjunell by email. As indicated, Felix had some questions about font sizes which were not necessarily clear in the Adobe Illustrator files sent by Ryan.

From Victor-Jan Vos:

Bar highlighting on which page you are is now quite invisible at the top, putting it underneath would probably be clearer

When viewing the RS site in German and clicking the statements there is an intermediary view displayed and then the declarations page is opened in English.
See screenshots below:

We introduce a vulnerability for our users by not checking for XSS in our additional paramaters

InC-OW-EU relatedURL 
NoC-NC date 
NoC-CR relatedURL 
NoC-OKLR relatedURL

For those browser that lack good XSS protection (Think of old browsers that sometimes run within public institutions this can create a vulnerability.

Example:

http://rightsstatements.org/page/InC-OW-EU/1.0/?language=en&relatedURL=%22%3E%3Cscript%3Ewindow.location%20=%22http://www.google.com%22%3C/script%3E

I suggest we make a simple check for the right dataformat before we present it to the users.

the short description text of the NKC, CNE, NOC-NC and NOC-CR contain the phrase "the organization that has published the Item”, while we use "the organization that has made the Item available” elsewhere (consitently in the body of the statements). This should probably be harmonised (since the short description is not part of the statements proper, this should be considered a minor issue at this point. We should move on this quickly since this is something that will propagate through all translations)

Reported by Victor-Jan Vos:

Better alignment of paragraphs like on this page http://rightsstatements.org/page/1.0/?language=en on the left side first and second para. Same here: http://rightsstatements.org/en/documentation/

See also this comp provided by @ryanjunell

From the minutes: "A short javascript message will be created to be displayed on the top of the page warning people that they are on a staging server when the domain is not rightsstatemens.org."

I suggest the logotypes and the titles (in red rectangles on the screenshot) of the individual declaration were also clickable (leading to the uri of the individual declaration).

Document containing the changes can be found here: https://github.com/rightsstatements/rightsstatements.github.io/blob/master/files/180524minor_changes_to_v1.0.pdf (or at https://docs.google.com/document/d/1UeoTOuUBLL7EsuJgLJdnayTmbucSPtRBJ6LQvDmy-A8/edit#heading=h.30j0zll).

Update change-log once the statements are updated.

This is a precondition for deploying the DE translation

On the FAQ page under "For Cultural Heritage Institutions> How Can I Use These Statements," the "guidelines for applying the rights statements" link is broken

Currently, the link points to http://rightsstatements.org/en/documentation/guidelines.html (page does not exist)
It should point to http://rightsstatements.org/en/documentation/usage_guidelines.html

From the minutes: "Allowing to edit the master branch, which automatically updates rightsstatements.github.io. Consequently we use rightsstatements.github.io as our staging environment."

Since we're using a personal access token with Travis's secure environment variables, we should avoid the token showing up in the Travis logs. Currently, we're seeing something like the following:

$ [ "${TRAVIS_BRANCH}" = "master" ] && [ "${TRAVIS_PULL_REQUEST}" = "false" ] && git push --force "https://${DEPLOY_KEY}@${GITHUB_REPO}" HEAD:${PRODUCTION_TARGET_BRANCH}
Counting objects: 11, done.
Delta compression using up to 32 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 321 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
To https://[email protected]/rightsstatements/rightsstatements.github.io.git
 + f8a9a77...9d20c21 HEAD -> pages-production (forced update)

$ [ "${TRAVIS_BRANCH}" = "master" ] && [ "${TRAVIS_PULL_REQUEST}" != "false" ] && git push --force "https://${DEPLOY_KEY}@${GITHUB_REPO}" HEAD:${STAGING_TARGET_BRANCH}

Can we add -q as a parameter to the two git push commands to prevent the output of the access token?

'to be used' is duplicated on vocab.md

https://github.com/rightsstatements/rightsstatements.github.io/blob/master/en/statements/vocab.md

I'd make a pull request to remedy this but I wasn't sure to which branch to use.

The translation guidelines encourage translation partners to translate the text of the home page and the about page. Now that the German translation is complete, we have a translation of the home page, the statements, and the page elements for the vocab page.

How do we handle partial translations of the site? What impact does this have on navigation? If users are on a partially translated site, should they only see the pages that have translated into whatever the active locale is?

From Victor-Jan Vos:

Hero image: I think it would be stronger to have an image (from DPLA or Europeana) that visually connects us to the subject like we have done with statistics (http://statistics.europeana.eu/)

The vertical spacing between the instances of each statements on the vocabs HTML representation is too small. This should be increased to about 10 px.

Moved from rightsstatements/data-model#49

From Victor-Jan Vos:

Alignment of the logos on the partner page is off http://rightsstatements.org/en/about.html

I'm wondering if it's because the logos have different aspect ratios, but I'm not certain.

The declarations page should have after the introduction a clearly brought out language selection (Declarations available in German, Estonian.) as on Creative Commons pages.

This also available in ... should be also on every page of individual declarations.

The question is could it be used separately from the site's language selection... For instance having the site in English but looking at declarations only in another language.

URIs need to be added for reference to RightsStatements pages. E.g. http://rightsstatements.org/page/NoC-CR/1.0/

The files in https://github.com/rightsstatements/rights-app/tree/master/conf contain an http link to creativecommons.org, this should either be changed into a https link or a protocol relative link. It looks amateurish that rs.org explicitly uses a http link whereas creative commons enforces ssl.

The site lacks social media meta properties which diminishes the richness of our social media outreach.

I suggest we add something like the following (draft) on our generic header and something programmatic on our statement pages:

<link rel="canonical" href="http://rightsstatements.org/en/" />
<meta property="og:locale" content="en_EN" />
<meta property="og:type" content="website" />
<meta property="og:title" content="RightsStatements.org" />
<meta property="og:description" content="RightsStatements.org provides 11 standardized rights statements for online cultural heritage." />
<meta property="og:url" content="http://rightsstatements.org/en/" />
<meta property="og:site_name" content="RightsStatements.org" />
<meta property="og:image" content="http://rightsstatements.org/files/images/logo.svg" />
<meta name="twitter:card" content="summary_large_image" />
<meta name="twitter:description" content="RightsStatements.org provides 11 standardized rights statements for online cultural heritage." />
<meta name="twitter:title" content="RightsStatements.org" />
<meta name="twitter:image" content="http://rightsstatements.org/files/images/logo.svg" />
<meta name="twitter:creator" content="RightsStatements.org" />

when unfolded there needs to be more padding (whitespace) between the question and the answer text. I would suggest applying the same amount of padding as under the answer text (and above the next question)

We need these ASAP.

When an institutions links to e.g. the French translation of the site I want to see a list with other languages (with their native name) so I can recognise that I can see the page in different languages as well.

the In Copyright - EU Orphan Work statement contains an incorrect use of the term "work" where we should have used "Item" in the optional line about finding more information in the EU-OW database:

[More information about the Work may be found in the following entry in the EU Orphan Works Database: http://example.com/1234567]

in line with the definition from the white paper this should be changed into

[More information about the Item may be found in the following entry in the EU Orphan Works Database: http://example.com/1234567]

Frontpage on emulated iPhone 6 screen in Chrome:

Statements page (/vocab/1.0/) at 1024x768:

Statements page (/vocab/1.0/) on emulated Nexus 4x (731x411):

Documentation page at 768x1024:

@anarchivist, following the discussion at #106, I've noted that we have not updated one of the examples of the Tech whitepaper (http://rightsstatements.org/files/170106requirements_for_the_technical_infrastructure_for_standardized_international_rights_statements_v1.2.pdf, skos:scopeNote on p15)

Also, I've spotted the Tech white paper still refers to OHIM while the Statement white paper does not anymore. @paul2keller should we remove it?

Example: www.rightsstatements.org/en sends you to a version identical to rightsstatements.github.io/en/.

This seems to apply to all pages, expect the statement detail pages such as www.rightsstatements.org/page/NoC-CR/1.0/?language=en

Unsure if this is related to DNS or the server. Issue would ideally be resolved during the switch to https. Status: EV SSL certificate is currently in validation process.

deploy the Estonian translation, based on the final approved translation document (see attached). This concerns both the statements and the parts of the website texts. Please refer to the approved german translation document for the texts:

180606RS_1.0_translation_EE_approved.pdf

From @paul2keller:

The horizontal spacing between the bottom of the hero image and the top of the grey text box is too big. Should be reduced by about 40-50%.

I really don't understand how the timing for publishing blog posts works:
I've tried to deploy a new blog post with date (in the markdown template) set to
date: 2019-05-28 12:00:00
That shows as 2019-05-28 05:00:00 -0700 in the preview https://github.com/rightsstatements/rightsstatements.github.io/blob/master/en/_posts/2019-05-28-rightsstatements-in-wikidata.md
How come that Wed May 29 10:09:02 CEST 2019 that blog post still didn't show up after deployment?
I've tried to deploy and re-deploy both site and webapp (yeah I know it should change anything, but I was desperate)

So I've to put an earlier date on the blog post, 2019-05-27 10:00:00 in the template (PR #188). That worked, and the blog post on the site showed a publication date of May 27.

I've put the old date back (PR #190) and re-deploy, just to double check. It is now visible, with publication data May 28. Is it just an hallucination?

Actually all this does look a bit like an hallucination: when I look at the history of the blog post at
https://github.com/rightsstatements/rightsstatements.github.io/commits/master/en/_posts/2019-05-28-rightsstatements-in-wikidata.md

I see my change of date to 2019-05-27 10:00:00 (with corresponding renaming) and then I do not see the change back to 2019-05-28 12:00:00, only the renaming of the file, without file change (see screenshot) Though it was in the PR #190.

Any clue on either problem?

When requesting https://rightsstatements.github.io/en/, I still get a Mixed Content warning for http://rightsstatements.github.io/fonts/445236/D0B47640DD2C49B64.css. This comes from the redirect configured at typography.com:

$ curl -i -H "Referer: https://rightsstatements.github.io/en/" https://cloud.typography.com/7018914/6677352/css/fonts.css
HTTP/1.1 302 Moved Temporarily
Server: Apache
Content-Length: 154
Content-Type: text/html
Location: http://rightsstatements.github.io/fonts/445236/D0B47640DD2C49B64.css
ETag: "348246c6e499ebd12050d9761d4cdc23:1521492159"
Expires: Fri, 14 September 2018 07:41:29 GMT
Last-Modified: Mon, 11 Apr 2016 17:47:03 GMT
Cache-Control: must-revalidate, private
Date: Fri, 14 Sep 2018 07:41:29 GMT
Connection: keep-alive

@anarchivist could you look into reconfiguring this somehow?

the three icons at the bottom are too big (there needs to be spacing between them). i would suggest to use the same size/layout as on http://rightsstatements.org/page/1.0/?language=en

Currently there is no language selector on the site to change the language of the site interface.

From Victor-Jan Vos:

On http://rightsstatements.org/page/1.0/?language=en I would expect the 3 icons to be clickable and lead me to the correct section

I'm guessing we'd want to achieve this using anchors. Maybe we can use the collection IDs? Other thoughts here are welcome.

This is the last remaining layout to implement from #6.

deploy the German translation, based on the final approved translation document. This concerns both the statements and the parts of the website texts. Please refer to the approved german translation document for the texts:

180525RS_1.0_translation_DE_approved.pdf

The easiest way to deploy the site accompanying rights-app is on GitHub pages. Ideally this would be the organizational account at rightsstatements.github.io because this plays well with the intended URL structure (i.e. exposing the static pages without a base path). Could you rename this repo to rightsstatements.github.io?

Raised in discussion with @literarymachine in rightsstatements/rights-app#64: we don't currently have translations of the error pages for 406 or 404 errors, and these pages are not included in what we expect a translation partner to translate. Should we do this?

In Usage Guidelines line 144

The following img src is not displaying an image:
http://rightsstatements.org/files/icons/InC-EDU.dark-white-interior.png

Hi, this is just a typo; should be "de" in the third place:
"description": [
{
"@language": "en",
"@value": "This Rights Statement indicates that the Item labeled with this Rights Statement has been identified as in copyright, but its rights-holder(s) either cannot be identified or cannot be located."
},
{
"@language": "et",
"@value": "Selle autoriõigusliku seisundi deklaratsiooniga märgistatud objektile kehtib autoriõigus, kuid õiguste valdajat (või valdajaid) ei ole võimalik tuvastada või leida."
},
{
"@language": "en",
"@value": "Dieser Rechtehinweis besagt, dass das damit gekennzeichnete Objekt urheberrechtlich geschützt ist, aber der/die Rechteinhaber entweder nicht identifiziert oder aufgefunden werden konnte(n)."
}
],

From @paul2keller:

we should also try to make the header image random (i.e chosen at random from a small number of images)

@paul2keller proposes a streamlined version showing all the variants of a given logo grouped together by box, e.g., the variants of InC-OW-EU would all be grouped together.

Example:

I believe that this is the last critical thing we need done soon; see #6 (comment). We still don't have FAQ content yet. Comp from #6 (comment).

This may be partially blocked by #47, but we could have a version of the page just linking to the SVG logo variations. Note that there are for versions of each logo.

For all the discussion on #138 and my reluctance to have explicit links to language-specific versions of the statements, I believe that if we have a link to "Deklaratsioonid" at http://rightsstatements.org/page/1.0/?language=et, which has value http://rightsstatements.org/et/statements/, then that link should really direct to http://rightsstatements.org/page/1.0/?language=et