Translating release posts

These steps are to be completed by the translator of a GA or Beta release blog post.

1. Clone the repo and create a branch off the default prod branch.

• From the prod branch, run: git checkout -b branch_name, where branch_name is a name you give your new branch.
• Do all your editing in this branch so that the blog editors can make any necessary edits directly in the branch before publishing your post.

2. Copy the .adoc file for the post that you want to translate into the proper language folder.

• All release post files are in the /posts folder of the cloned repo. You can find your file name by looking at the URL of the release post. For example, the URL for the 24.0.0.5 release post is \https://openliberty.io/blog/2024/05/21/24.0.0.5.html. The corresponding file name is 2024-05-21-24.0.0.5.adoc.
• Copy the file and paste it into the /posts/* subfolder for the language that you are translating into, for example posts/ja. Do not change the file name. If no folder exists for your target language, contact a blog administrator to create one for you.

3. Translate the post into your target language.

• Follow the local IBM translation policy.
• Links: Check link addresses to ensure they match the link addresses in the original blog post. Check that text within links is properly translated.
• Code blocks should remain in English (unless you know you have a specific code block that should be translated).
• If the post includes a Stack Overflow button, update the Stackoverflow link with your language. (Adding _ja in the svg file name.)

[link=https://stackoverflow.com/tags/open-liberty]
image::img/blog/blog_btn_stack_ja.svg[Stack Overflowで質問する, align="center"] 

4. Update the post metadata at the beginning of the file.

• Add the additional_authors field to specify translators credit and the blog-available-in-languages: field to link to the translation to the original post. The following code block shows how to add this field to the end of the metadata section in your translated file.

---
layout: post
title: "Open Liberty 23.0.0.10でJava 21をサポート"
# Do NOT change the categories section
categories: blog
author_picture: https://avatars3.githubusercontent.com/lauracowen
author_github: https://github.com/lauracowen
seo-title: Open Liberty 23.0.0.10でJava 21をサポート - OpenLiberty.io
seo-description: 2年前のJava 17以来の長期サポートリリースとなるJava 21をサポート。今すぐお試しください。
blog_description: 2年前のJava 17以来の長期サポートリリースとなるJava 21をサポート。今すぐお試しください。
open-graph-image: https://openliberty.io/img/twitter_card.jpg
open-graph-image-alt: Open Liberty Logo
additional_authors:
- name: 浅田 かおり (翻訳)
  github: https://github.com/kaori-asa
  image: https://avatars0.githubusercontent.com/kaori-asa
blog-available-in-languages:
- lang: en
  path: /blog/2023/10/17/2023-10-17-23.0.0.10.html
---

5. Update the metadata in the original English file to reference your translated file.

• Add the blog-available-in-languages: field to the original English file to link it to your translation. The following example shows how to add this field to the end of the metadata section in the original English file.

---
layout: post
title: "Default verbose garbage collection and OpenID Connect back-channel logout support in 24.0.0.3"
# Do NOT change the categories section
categories: blog
author_picture: https://avatars3.githubusercontent.com/dmuelle
author_github: https://github.com/dmuelle
seo-title: Default verbose garbage collection and OpenID Connect back-channel logout support in 24.0.0.3 - OpenLiberty.io
seo-description: Starting in 24.0.0.3, verbose garbage collection is enabled by default when your Java implementation is IBM Java or IBM Semeru Runtimes. Also in this release, OpenID Connect clients and servers in Open Liberty now support back-channel logout.
blog_description: Starting in 24.0.0.3, verbose garbage collection is enabled by default when your Java implementation is IBM Java or IBM Semeru Runtimes. Also in this release, OpenID Connect clients and servers in Open Liberty now support back-channel logout.
open-graph-image: https://openliberty.io/img/twitter_card.jpg
open-graph-image-alt: Open Liberty Logo
blog-available-in-languages:
- lang: ja
  path: /ja/blog/2024/03/26/24.0.0.3.html
---

6. If you are not employed by IBM, in at least one of your commits, sign off the commit using the Developer Certificate process.

7. When you have finished the post, check that it renders correctly. If you have a preview function in your editor, use that (eg the Asciidoc plugin in VSCode). Otherwise, you can check that GitHub renders it properly when you push to GitHub in the next step.

8. Push the file to GitHub, then create a pull request (PR) into the draft branch.

• If you've been working in a fork for some reason, create a feature branch [see Step 2] and push your changes to the feature branch, then create a PR to the draft branch from there.
• If you find there are a load of merge conflicts at this stage, see Troubleshooting GitHub workflow.

9. All the builds and deployments of non-prod sites run on IBM Cloud and build automatically whenever a PR is merged into their respective branch. These builds are private and, therefore, their detailed build/deploy progress can't be tracked. However, if you have access to the Slack channel for draft site or the Slack channel for staging site, you can at least track when the builds start and finish.

10. When the build is finished, check that the blog renders correctly on the blogs-draft site.

• To find your translated post, go to the English version on the blogs draft site. Look for the Post available in languages field at the beginning of the post. This field show your language if you correctly updated the source file metadata in step 5.Click your language to review the translated draft.

• If you see any problems , such as formatting issues or typos, resolve them first in your branch. Then, create another PR into draft branch and get the PR merged. Wait for IBM Cloud to rebuild blogs-draft site and verify the change.

11. When you're happy with the post:

• Create a PR from your branch (not from the draft branch) to the staging branch.
• In the PR, provide a link to your post on the blogs-draft site.
• Add @dmuelle as a reviewer, as well as any other reviewers to get their final approval for both content and format.

12. The editors will now review and edit the post. Please respond to any questions they ask or suggestions they make. Their aim is to make the post readable and useful to its target audience.
13. If you need to make changes based on review comments, as before:

• Make any changes in your feature branch
  • The updates that you make to your branch for the draft PR will be automatically picked up by your staging PR; there is no need to update it.
• Create a PR to the draft branch
• Merge the PR
• Once the site rebuilds, check that everything is correct on the blogs-draft site.

14. Get reviewers to review the updates in your new PR.

You're done! The editors will handle the rest.