Quote from: GazetaBitcoin on Today at 08:24:03 AM

Quote from: nullius on November 01, 2020, 08:19:23 PM

I don’t mean to thrust on you a new project, much less suggest when you could do it. From experience in working with you on translations, I know how much time and effort you devote to such projects; and although the whitepaper is not long, translation of the technical details presents a formidable task. It would probably take you some time.

I do know that it would be for you a labour of love, and an achievement that you would value independently of any forum political fights.

What say you?

Me says yes!

Excellent!

If the IkeGDB translation is so bad...

Quote from: NeuroticFish on Today at 06:45:26 AM

Shame on me, I didn't check the Romanian translation, but from the images attached it's indeed bad, I can confirm that.

...I do agree with this:

Quote from: Little Mouse on Today at 11:46:31 AM

I have planned to translate the white paper and submit it again. I think you should do the same, forget everything else.

An independent translation would probably be less effort than trying to fix somebody else’s mess; and why should an incompetent translator retain byline credit for the result of painstaking line-by-line corrections?

Based on my prior experience of working with you on your volunteer translations of Bitcoin advocacy essays (plus my political manifesto!), I have confidence in your own work.

Note: Whitepaper translations are probably accepted into the bitcoin-dot-org repository only in a specific file format, or a set of file formats. I have my own opinions about how this should be done; but I am not the maintainer of that repository, and I have no idea how they handle it.

How to contribute on Github

Quote from: nullius on November 01, 2020, 08:19:23 PM

It’s open-source. File an issue. Ask other Romanians for review, too.
https://github.com/bitcoin-dot-org/bitcoin.org

And if you were to create a translation, you could create a PR (Pull Request).

I should elaborate. I don’t want to scare you off with a learning curve; and I would not suggest that you should take the time and effort of learning all of the below for only one contribution. But since you care about open-source software, this is a generally useful skill. Whether or not you write code, you may wish to contribute translations, documentation, and also, well-made bug reports that help developers. Learning this once will open a whole new world to you!

Github has detailed help pages. Use them, especially this: “Collaborating with issues and pull requests”.
Open an issue concisely describing the problem with the Romanian translation, and noting that you will offer a better translation. Avoid discussion of the personalities involved, unless it is necessary. Well-run Github projects are meritocracies; competent maintainers try to avoid drama. If someone else tries to raise drama, take the high road—unless it turns out that the maintainers are total idiots, in which case the project will probably fail anyway unless it has big corporate backers.

I don’t want to sound negative. It’s just that Github newbies oftentimes don’t realize that every comment on every issue gets spammed to a whole bunch of busy people, most of whom are interested only in project management. They definitely appreciate comments that help with project management! If you wonder why many Bitcoin Core developers have forum accounts that have been inactive for years, or are barely, rarely active, this probably explains why. :-(
In the ensuing discussion, if you simply agree or disagree with a comment without substantive reply, feel free to use the little emoji buttons to express thumbs-up, thumbs-down, heart, “confused”, “party”, etc. Again, Github issues are a place for practical project management, not a forum; usually, excessively verbose discussion should be avoided. Of course, if you have a substantive remark that will help project maintainers, don’t be shy about expressing it!
Issue and pull request comments use Markdown for formatting; Github uses CommonMark, with “GitHub Flavored Markdown” extensions. There is a Github Guide for this. At-mentions work (@username). There are also some tricks for cross-references, e.g. #1234 would automagically link to issue or PR #1234 in the same repository, with a backlink; bitcoin/bitcoin#19953 would link to/backlink from the PR merging Schnorr/Taproot consensus rules into Bitcoin; and bitcoin/bitcoin@8bbed4b (the first seven hexadecimal digits of the commit hash) would reference the commit implementing Taproot validation. (Please don’t spam that PR and commit with references from irrelevant issues!)
Make a fork of the main repository, make a branch within your fork, and commit your work to the branch. Read the pull request documentation to understand why.
If you wish to request several distinct actions, make atomic commits to your branch. For example, if you wish to delete the bad translation and add the good translation, make those actions into two separate git commits which can “upstreamed” together in one pull request, as I will briefly describe below.
Learn “How to Write a Git Commit Message”. Don’t overdo it; just follow the guidelines. Using the customary style for commit messages shows professionalism, and it really does make things easier for the people who will read the commit log in the future. “The Seven Rules” are not arbitrary, as you will understand if you ever accrue experience reading commit logs.

Bitcoin Core’s commit logs are exemplary, albeit probably incomprehensible to non-coders. On the flipside, I can “smell” a bad project by the odour of sloppy commit logs.
If you want to secure your commits, add a PGP key to your Github profile before you commit anything, and sign your commits. This is an absolute requirement for security-critical code; n.b. that all of Bitcoin Core’s commits show “Verified” status. It arguably may be less important for a whitepaper translation; but if you really want to do things right, invest some time to learn a process that will be fast and easy thereafter. N.b. that you cannot go back and retroactively secure commits that were made without digital signatures.

(If I were to manage a public repository of any kind, all substantive commits would require signatures as a matter of policy. Most repositories do not have such a policy.)
File a pull request (PR). This is the action that asks the project maintainers to merge your branch’s commits into the project’s “master” branch. In your pull request, reference the issue that you raised with specific language that Github recognizes automagically. For example, if you raised Issue #1234, then say your pull request’s text, Closes #1234. or Fixes #1234. This way, the issue is automagically hyperlinked bidirectionally; and if your PR is accepted, the Github system will close your issue with an appropriate note and cross-reference.

If you have any questions that cannot be easily answered by the Github docs, please feel free to ask here, or ping me off-forum if that would be more appropriate.