Open ddbeck opened 4 years ago
Per https://github.com/mdn/stumptown-content/pull/248#issuecomment-554655518, I think only title
, short_title
, and mdn_url
need to be localizable.
Things referenced by a path, like examples, are interesting cases. I think we've decided that paths and filenames are not localizable, so "examples/a_simple_example.md" will be the same across all locales.
I would like to know what @SphinxKnight thinks about this proposal though.
(needless to say that I should consume my GitHub notification in a more efficient manner, sorry all for the lag)
I agree with @wbamberg here, having paths and filenames being not localizable is a way to prevent "localization slug mess" (as we can now observe in kuma). On the other hand mdn_url
should be localizable in order to have a "visual" slug which is more relevant locale-wise semantically (indexing for search engine, etc.)
There is also a category of content which ultimately should be translatable elsewhere (aka Pontoon but not in the markdown file itself) where "non-code" keywords are reused in many articles and where the English value may be used by either stumptown-content / renderer. I'm thinking about tags
(group
), tag_omission
, etc. I think describing those by "non-paths/non-code keywords" fits quite well.
I'll check for existing issue / will open a new one for strings that should go through other localization process ("non-paths/non-code keywords" in frontmatter but also recipes ids).
Addendum:
Path for "children" content (ex. static_methods
for JS classes) or links (link_lists.pages|directory
) are somehow "localizable" since the locale fragment is explicitly part of the content and might one day (hopefully) be changed from en-US
to localeX
.
I'm not fully satisfied by this (as having the full URL seems counterintuitive to relative paths) but it somehow "incentivize" explicitly translation of other contents and avoids complexity for resolution when the localized content does not exist.
Originally posted by @Elchi3 in https://github.com/mdn/stumptown-content/pull/248#issuecomment-554659605
Is there anything else we can identify as unlocalizable now?
Fixing this issue would probably involve:
build-json
to use en-US frontmatter while building non-en-US pages