translate metadatagroup field label with field metadata instead of value 2 #11
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
References
Add references/links to any related issues or PRs. These may include:
superseeds
Description
The metadatafield label of metadata groups is currently translated wrong.
According to the autogenerated i18n Keys in the layout.xls the Scheme
"layout.field.label.<EntityType>.<Metadatafield>": "<Value of Translation>"
should work, but instead the translation for the value
"layout.field.label.<Label of Metadatafield>"
is being requested.
Alternative way of solving this issue:
This issue could also be solved purely by configuration with changing the layout.xls$metadatagroups column Label to .. In this case the formula in the metadatagroup_i18n sheets is calculated wrong and could be changed. Since diffs in the excel file are hard to read, we prefer the first approach ;)
Instructions for Reviewers
Please add a more detailed description of the changes made by your PR. At a minimum, providing a bulleted list of changes in your PR is helpful to reviewers.
Checklist
My PR is small in size (e.g. less than 1,000 lines of code, not including comments & specs/tests), or I have provided reasons as to why that's not possible.
My PR passes TSLint validation using
yarn run lint
My PR doesn't introduce circular dependencies
My PR includes TypeDoc comments for all new (or modified) public methods and classes. It also includes TypeDoc for large or complex private methods.
My PR passes all specs/tests and includes new/updated specs or tests based on the Code Testing Guide.
If my PR includes new, third-party dependencies (in
package.json
), I've made sure their licenses align with the DSpace BSD License based on the Licensing of Contributions documentation.