search

mdn / stumptown-content

Other
22 stars 19 forks source link

Some frontmatter shouldn't be localizable #252

Open ddbeck opened 4 years ago

ddbeck commented 4 years ago

specifications shouldn't be localizable

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:

  1. change build-json to use en-US frontmatter while building non-en-US pages
  2. lint against providing unlocalizable frontmatter in localized pages
wbamberg commented 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.

SphinxKnight commented 4 years ago

(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.