Open katherinejensen00 opened 5 days ago
tombogle
commented
5 days ago These are already localizable in P9. The strategy there might not extend to our world where the checks are less of a closed set, but so perhaps we can look at how it's done in P9 to see. Our strategy will also need to account for checks that are developed in an extension, but there I'm guessing the existing Platform localization strategy should cover the need.
tjcouch-sil
commented
2 days ago Regarding taking advantage of Paratext 9's localized strings, there's a bullet called "Paratext 9 Fallback Keys" in the style guide that explains how we should structure our localized string metadata in order to prepare for pulling forward the P9 localization data from Crowdin one day (we have not done this yet but plan to do so).
Essentially, if there's already a string in P9 that matches the text and purpose of the string you're making in Platform.Bible, you should add the P9 string key as a fallback. There's an example linked in the style guide :)
Sebastian-ubs
commented
1 day ago Also have in mind that for settings we talked about the ability to search settings using the old setting name, even when we use a new one in PT10. We might want to do something similar for other areas of the product as well, so e.g. if there is a filter to filter checks and we decide to rename a check, still you should be able to filter by the old name and get a reasonable hint (to be defined how that looks like) about why this matches. For this I have created
User Story As a user, I want to see check names in my interface language so that I know which checks I am running.
Description Localize check names.
Implementation idea