Home
Welcome! This wiki serves as the documentation for this project. You may also join Freenode#ruby-lang.org on IRC.
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).
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.
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
- Always use feature branches, never commit to
masterdirectly. - 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).
Examples:
"Fix code example on About page (en)""Translate latest news posts (de)""Fix typos (zh_cn)"
"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.
-
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.)
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
langvariable to the correct language code. - Do not modify code examples (comments in code may be translated, though).
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).
To create a new post, use e.g.
rake new_post:enwhich 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.
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: ...
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.
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.
If you hope to get permission to access google analytics of ruby-lang.org, you can create an issue and mention to @hsbt.