Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Welcome! This wiki serves as the documentation for this project. You may also join Freenode#ruby-lang.org on IRC.
Want to contribute? Read this first :)
Much like a wiki, ruby-lang.org is editable by its readers. Unlike a wiki though, the editing process does not take place on the website itself; instead, it happens here, on GitHub. If you don't know about Git, head to Git's official website, or consult the very apt and to-the-point GitHub help on Git.
Making changes to ruby-lang.org is quite easy:
- find something to add/fix/update
- propose your change here (how exactly? See below)
- wait for a review and approval
- enjoy once your change has been deployed!
How to propose a change
If there is something you want to edit, the process is rather simple. First, create a GitHub account and log in. Then, it depends on whether you want to do a quick edit, or something more involved.
The quick way
Simple edits may be performed directly on GitHub, using the "Edit" button while browsing the file you want to edit:
- head to the repository containing the website code
- browse the files to display the one you want to edit (a description of the project structure is available here
- click on "Edit" and make your changes
- When everything looks fine, click the "Propose File Change" button
- Provide a good rationale for your request, and click on "Send Pull Request" to complete the process
A new pull-request will be created with your changes. A member of the editorial team will review your request and eventually merge the edits in if all is good. If not, you will most likely receive some insights through a comment on your pull-request and will be automatically notified.
If you plan to perform regular and/or large-scale edits, you may want to clone the repository instead, so that you can work and preview on your local machine before submitting changes. Here's the process:
- head to the repository containing the website code
- follow the instruction on the README (
git cloneand installation guidelines)
- Make your changes on a topic branch, using maintainer-friendly policies
- Follow the GitHub guide on pull-request to create a new request
Guidelines for contributors
Commits and commit messages
- Always use feature branches, never commit to
- Never merge
masteror other branches into your feature branch.
- Make commits of logical units. Feel free to use
git commit --amendand repush to fix open pull requests.
- Commit messages must be in English.
- They should be short and descriptive. Reasoning or comments do not belong there; tiny changes (like fixed typos) do not need long explanations.
- The affected translation should be mentioned in the commit message, see the examples below.
- Try to follow "50/72 formatting" (first line: 50 characters or less, remaining text: wrapped at 72 characters).
"Fix code example on About page (en)"
"Translate latest news posts (de)"
"Fix typos (zh_cn)"
Corrections on translated sites
"Translated site" means, a version other than the mainstream English one.
When you find an error on a translated site that is not language specific --like, say, a typo in a code snippet-- consider opening an issue or pull request for the English site, that will essentially serve as the "master" issue for the various translations. Using checkboxes for languages and notifying lang maintainers is a good way to go.
Markdown, Link References, ...
The markdown on translated sites should be kept as close as possible to the English site.
Named link references: when links are removed or added to a page, the existing link numbers should not be updated (in order to create a gapless sequence of numbers); this makes diffs between commits and also between the English and translated, not yet updated pages much more easier to read.
For new links, short descriptive names are much preferred over numbers.
(The link numbers originate from the migration of the site to Jekyll, where they were automatically created.)
Notes for translators
When translating pages and news posts the directory structure and filenames
of the English site should be kept.
This makes it easier to find and compare corresponding pages and news posts.
(Posts are located in the
news/_posts/ directory of the respective
So, simply copy the original page or post to the corresponding directory for your language and start translating!
- Keep the original filename.
- Keep the original author and publication date in the front matter.
- Remember to set the
langvariable to the correct language code.
- Do not modify code examples (comments in code may be translated, though).
Notes for news post authors
Use short but descriptive filenames.
A good example is
2014-10-27-ruby-2-1-4-released.md(note that the date part is obligatory).
Use absolute URLs even for internal links (because of the RSS feeds).
Creating a new post
To create a new post, use e.g.
which will create a template for a news post for
Then rename the file to contain an appropriate title
(but do not change the date part) and start typing!
Note: For translations you should simply copy the original post to the appropriate directory, keeping the filename.
Security related posts
News posts about vulnerabilities and other security issues must
be tagged in the YAML front matter like shown below,
in order to get included in the list on the
date: ... tags: security lang: ...
Notes for maintainers
Branches and merging
Use feature branches.
Preview your changes before merging (
bundle exec rake preview).
Do never merge the modified master branch into your feature branch. Merge your feature branch into master (possibly after rebasing it onto master).
And remember to always fetch the most recent changes from the remote master branch before merging.
If you are not sure about your changes, you can also push your feature branch and open a pull request for discussion.
Issues and pull requests
When reviewing issues or pull requests, maintainers should examine whether
the reported problem applies to their language only, or to all translations,
or also to the
ja versions, and act accordingly.
How to get analytics account.
If you hope to get permission to access google analytics of ruby-lang.org, you can create an issue and mention to @hsbt.