-
Notifications
You must be signed in to change notification settings - Fork 15
DRYD-1938: DetailList QA Updates #308
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: develop
Are you sure you want to change the base?
Conversation
spirosdi
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good, regarding "(field collector)" i18n, I am not sure either. @jessiweithman what do you think?
| id="detailList.collectionobject.concepts" | ||
| description="The prefix for content concept tags in the search detail view" | ||
| defaultMessage="Content Concepts: " | ||
| defaultMessage="CONCEPT TAGS: " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
please intl this
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@spirosdi I added a messages object to each formatter which uses any text which needs to be i18n'd and allows the messages to show up when we run generateDocs.js. Though this did make me question whether or not we should just pass the intl object to the formatters instead of relying on FormattedMessage. Thoughts?
What does this do?
Why are we doing this? (with JIRA link)
Jira: https://collectionspace.atlassian.net/browse/DRYD-1938?
These are changes requested from QA as there were some differences in the text as well as the behavior in some of the logic due to de-urning failures.
How should this be tested? Do these changes have associated tests?
npm run devserver --back-end=https://core.dev.collectionspace.orgcontentConceptsshould displayCONCEPT TAGS(field collector)Dependencies for merging? Releasing to production?
I'm wondering if we should i18n the
(field collector)part now as it is being passed from the server with no option otherwise.Has the application documentation been updated for these changes?
No, as these updates are being done in order to match the documentation.
Did someone actually run this code to verify it works?
@mikejritter has been testing using core.dev as a backend