Live data from Hacker News

MDN Web Docs evolves: Lowdown on the upcoming new platform

hacks.mozilla.org

181–190 of 202 posts

Re: MDN Web Docs evolves: Lowdown on the upcoming new platform

#181
post #141
post #30

Earlier quoted context omitted.

We shouldn't discount volunteer translations. Won't the new platform support that?

I think that storing the localized content in separate flat HTML files makes it very difficult to maintain translations, as the article points out. Ideally, you would have a master document in which some parts are shared across all translations (like the layout, the actual terms in the spec, browser compatibility information, etc), while other parts were localizable (like the field descriptions). Then when content wa…

It's quite telling already that they basically admit that mixing markup and content as tightly as that is problematic.

I mean I don't think it's actually that big of a deal as long as they stick to basic HTML markup (paragraphs, bold/italics, etc), but you're already running into problems when you add links.

Not having multi-language support as a first-class citizen is a step backwards IMO. Especially considering the world is still getting connected at an enormous rate.

Re: MDN Web Docs evolves: Lowdown on the upcoming new platform

#182

Earlier quoted context omitted.

I still don't fully grok the term. Is it a loose/blanket term sorta like 'devops' or is it a more literal prescription of actual requirements and practices?

I can get that a significant part of it is just "static HTML," what I don't quite get is what makes it different than just static site generation. I guess that would be the "A" part...

It mostly concerns how often content is updated.

Real-time: dynamically generated on the server-side. (e.g. injecting the current user's username)

Occasionally: Jamstack (e.g. rebuilding a static site every time a contributors adds a blog post via the CMS)

Rarely: manual updates (e.g. manually deploying a new version of a small-town restaurant's website when the menu changes)

Re: MDN Web Docs evolves: Lowdown on the upcoming new platform

#183

Earlier quoted context omitted.

Can we have both PR and WYSIWYG? Login with github, Edit page, click button to submit PR with your changes.

In theory, yes; Github is working on / has deployed a web-based version of VS Code, and VS Code has a Markdown preview (and I'm sure there may be a WYSIWIG / Markdown editor as well). It should be doable to create a WYSIWYG editor just for the MDN pages as well, or any static site generator for that matter. Question is whether they want to invest in that; will that actually improve things, given how the MDN pages are…

That's yet another option, authoring Markdown with preview.

I've thought of GitHub REST API Pull Requests [1] this requires authorizing web application though.

Another version - is there any service that allows to post changes in Pull Request body? Maybe extend GitLab? Workflow would be Edit page, Preview, copy to clipboard, open new Pull Request, paste.

I am not a fun of Markdown anymore. WYSIWYG looks like much better approach, it already there. HTML to markdown tools are not great.

[1] https://docs.github.com/en/free-pro-team@latest/rest/referen...

Re: MDN Web Docs evolves: Lowdown on the upcoming new platform

#184

Earlier quoted context omitted.

If the text is in github, you can download it, backup, make an iso and share on piratebay, it won't be lost.

The concern I'm trying to express is that the translations of this content will grow increasingly stale as the original articles are updated, and will be missing entirely for new articles. People who don't speak or read one of the top 12 languages will just be out of luck, unless some generous soul decides to do that substantial amount of work for free.

As far as I understand Mozilla's point is that this is already happening. I agree that stuff like the UI should still be localized manually.

Re: MDN Web Docs evolves: Lowdown on the upcoming new platform

#185
post #141

Earlier quoted context omitted.

I think that storing the localized content in separate flat HTML files makes it very difficult to maintain translations, as the article points out. Ideally, you would have a master document in which some parts are shared across all translations (like the layout, the actual terms in the spec, browser compatibility information, etc), while other parts were localizable (like the field descriptions). Then when content wa…

It's quite telling already that they basically admit that mixing markup and content as tightly as that is problematic. I mean I don't think it's actually that big of a deal as long as they stick to basic HTML markup (paragraphs, bold/italics, etc), but you're already running into problems when you add links. Not having multi-language support as a first-class citizen is a step backwards IMO. Especially considering the…

Multi-language support has the inherent problem that is requires effort linearly in the number of languages. Wearing a hopeful hat this new architecture would only require an effort "linear" to the error rate of the machine translations.

Personally I had some very good experiences with some translators, and it could work even better if Mozilla manages to tune and train them properly. (Like making so that manual fixes improve the algorithm)

Re: MDN Web Docs evolves: Lowdown on the upcoming new platform

#186
post #31
post #16

Earlier quoted context omitted.

Man these kind of views bother me so much. They’re taking one of the most (if not, most) useful documentation sources for cross platform web development that benefits them very little, and moving it to a system of open contribution so it can live past the company’s financial problems. And this is your first take?

I think you are both right. This is good for the future of MDN, but OTOH cutting cost is likely to be what motivated Mozilla to make this change.

They had already cut cost, I would phrase it as this change being now even more necessary.

Re: MDN Web Docs evolves: Lowdown on the upcoming new platform

#187

Earlier quoted context omitted.

This is an article about MDN, not Mozilla. How exactly does MDN bring money? Do you suggest MDN should be a revenue source? Or do you expect Mozilla to maintain the MDN for free eternally just because? This is seriously entitled. Mozilla gave us an amazing resource, entirely for free. This attitude isn't right, it's toxic and harmful. Mozilla is in a spot of difficulty, and instead of taking a resource that is operat…

> Or do you expect Mozilla to maintain the MDN for free eternally just because? That's what I expect of a non-profit organization dedicated to maintaining one of the last two remaining major browser engines, yes.

I didn't know that becoming non-profit meant that money is free :)

Re: MDN Web Docs evolves: Lowdown on the upcoming new platform

#188
post #75

Earlier quoted context omitted.

For the arrow coming from github to the cdn, I would bet that's a deployment where the existing docs site gets deployed as a lambda. From there, CDN calls that aren't cached go to the lambda which are then served up.

If that’s the case, why not just use GitHub Actions? It’s more integrated and requires no setup.

They are probably more interested in cost rather than setup.

Re: MDN Web Docs evolves: Lowdown on the upcoming new platform

#189
post #129

IIRC Microsoft a few years back decided to throw in with MDN as THE source for web API docs: https://mspoweruser.com/microsoft-redirect-7700-msdn-pages-m... > Microsoft is joining Google, the W3C, and Samsung to make Mozilla’s MDN Web Docs as the single place for web API reference. Now that Microsoft is on Chromium, and THAT is also documented in MDN, and Google and Microsoft both own public cloud providers.. I feel…

This also match the focus on mass edits and tooling in the article

Re: MDN Web Docs evolves: Lowdown on the upcoming new platform

#190

I don't know. Moving from a Wiki model to a GitHub PR model actually sounds worse for users. They talk about, "building a relationship with contributors". This could also be called, "building a lot of friction for contributors". With a Wiki, even non-technical users can contribute, because the editing tools are all built in. But with the PR model, now contributors need to understand HTML, CSS, Git, and GitHub PRs. I'…

> Does Microsoft wring its hands over how much running MSDN costs

Microsoft revenue stream is slightly more reliable than Mozilla's reliance on Google.

Post reply on HN