Yari does a good job today of flagging when an internal link uses a language code link that doesn't exist (yet) and will fall back to the en-US version.
Where it could be enhanced is to flag when an invalid language code is used in an internal link.
Macro is using {{page('zh-US/docs/JavaScript/Reference/Global_Objects/DateTimeFormat','Parameters')}} with an invalid language code
Other ones i've come across:
/en/ & /zh/ under specified language code
/ja-US/
Expected behavior
If the link or macro path isn't in an allow list of supported languages, Yari should raise a warning.
External links like MSDN that use language codes would be ignored.
Actual behavior
Warnings are raised that it will fall back to /en-US/ version, even if there is a correct localized document.
We would accept a community PR that extends build/flaws/broken-links.js to emit a flaw for /{locale}/docs links where {locale} is not a supported locale. 👍
Summary
Yari does a good job today of flagging when an internal link uses a language code link that doesn't exist (yet) and will fall back to the
en-US
version. Where it could be enhanced is to flag when an invalid language code is used in an internal link.URL
https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Date/toLocaleTimeString
Reproduction steps
{{page('zh-US/docs/JavaScript/Reference/Global_Objects/DateTimeFormat','Parameters')}}
with an invalid language code/en/
&/zh/
under specified language code/ja-US/
Expected behavior
If the link or macro path isn't in an allow list of supported languages, Yari should raise a warning. External links like MSDN that use language codes would be ignored.
Actual behavior
Warnings are raised that it will fall back to
/en-US/
version, even if there is a correct localized document.Device
Desktop
Browser
Firefox
Browser version
Stable
Operating system
Windows
Screenshot
No response
Anything else?
No response
Validations