Home

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!

The website is updated on a regular basis: your approved edits will show up when a team member triggers a new deployment (usually right after the edits have been approved).

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.

Long-term edits

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 clone and 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 master directly.
Never merge master or other branches into your feature branch.
Make commits of logical units. Feel free to use git commit --amend and 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).

Examples:

"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 language.)

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 lang variable to the correct language code.
Do not modify code examples (comments in code may be translated, though).

Notes for news post authors

General hints:

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.

rake new_post:en

which will create a template for a news post for en. 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 security/ page:

date: ...
tags: security
lang: ...

Notes for maintainers

Branches and merging

Use feature branches.

Preview your changes before merging (follow the instruction on the README).

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 en or 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.

ruby / www.ruby-lang.org