4 ms·
Both your webpage and your docs are riddled with typos and the like. While it isn't indicative of code or project quality, it sure makes taking the project seri
by Etheryte 10y ago
Both your webpage and your docs are riddled with typos and the like. While it isn't indicative of code or project quality, it sure makes taking the project seriously a lot harder.
- paraboul 10y agoHey, We're French and it's indeed hard for us to get this perfectly right and focusing on the project itself at the same time. We're planning to move this to github in order to let the community help us on this.
- JustSomeNobody 10y agoJust because I'm curious, why would you not use your native language for the content on your page?
- blueprint 10y agoSeems an easy question. English is basically a/the global language. If you want a massive portion of the community to find the content inaccessible, making it available only in French is a good way to do so.
- paraboul 10y agonidium is an open source tech project not a local product.
- poirier 10y agoStarred because your answers here are beautiful.
- collyw 10y agoBecause English is the most spoken language in the world perhaps? Its even more noticeable in tech, because a lot of docs only seem to be in English.
- acuozzo 10y agoI'm more than willing to help edit the English you write for this project. Let me know if you're interested.
- paraboul 10y agoDefinitely! My email is my HN handle at gmail
- saosebastiao 10y agoHey, I think you're doing the right thing, in 1) asking for help from the community in an area where you feel lacking, and 2) by making it available to the best your ability. Many projects fail at one of those two, which dooms them to never have a community. Keep up the good work.
- franciscop 10y agoWell it depends on how much you have worked with a person who was still learning English. For me it highly depends on the kind of typos: - They're vs Their and similar normally denote uneducated native English speaker. The code might still be okay, but these typos passing to production makes me check code quality in case some similar QA mistakes are passed in the code. - Grammar mistakes normally show a foreigner for whom English is not the main language. A small example just in the first line, "to create apps, games that run" => "to create apps and games that run", but this is normally due to a different language constructions. Similar to graphical softwares => graphical software. So, kudos for OP to write the documentation in a non-native language! (upon light investigation it seems the main writer is French and his coworkers fix typos from time to time).
- merb 10y ago> They're vs Their and similar normally denote uneducated native English speaker. in germany only grammar nazi's would actually hate such things. they are too common, to say that only uneducated people do it. people who write code and distribute code to the whole world are not writers, there is no need for "perfect" grammar and typos. i mean in my first application i've written quanity instead of quantity (inside the code), somehow it slipped in a lot of places, but i think many many people who will read the code would still understand it. as long as the user interface is checked, i think it's okay if the readme/documentation has typos or grammar mistakes (on open source projects). the most important thing is, is that people understand each other/understand what it's all about. which is just fine for nidium.
- franciscop 10y agoReally? I have seen it in many "comment sites" but rarely see it in technical documentation and blog posts. And I don't hate that at all! I'm just pointing out that someone who makes these kind of mistake is probably native and that a large number of these typos indicate that: - The writer didn't do proofreading (or did it but is not aware of the mistake). - It's made by a single person with no one else to check on the documentation. Now while they are not technically a display of low code quality, they are normally indicative of low attention to detail and lonely programming, which is not the optimal situation for high code quality. For people using English as the second language I'm a lot more forgiving since they and their coworkers might not even know how to properly express some things due to translation issues (and not due to lack of proofreading/lonely programming). In my experience when I'm doing proofreading of my own libraries I also catch ambiguous sentences, lacking documentation or examples and many other things that could be improved upon.