diff --git a/_articles/pidgin/best-practice.md b/_articles/pidgin/best-practice.md
index cf706933210..195f3d1d556 100644
--- a/_articles/pidgin/best-practice.md
+++ b/_articles/pidgin/best-practice.md
@@ -55,7 +55,7 @@ If to maintain your project na part-time or you dey do am because you volunteer,
[Jekyll](https://github.com/jekyll/jekyll/tree/master/docs), [CocoaPods](https://github.com/CocoaPods/CocoaPods/wiki/Communication-&-Design-Rules), and [Homebrew](https://github.com/Homebrew/brew/blob/bbed7246bc5c5b7acb8c1d427d10b43e090dfd39/docs/Maintainers-Avoiding-Burnout.md) na some examples of projects wey get rules for maintainers and contributors.
-### Make Your Communication Public
+### Make Sure Your Communication Commot For Outside
No forget to write down your talks. Where you fit, make all your communication for your project public. If person try contact you for private to discuss feature request or support matter, tell am politely make e follow public channel yarn you like mailing list or issue tracker.
@@ -69,7 +69,7 @@ Saying no no dey fun, but make you try yarn "Your contribution no dey follow thi
You go fit yarn no for plenty situations wey you go see as maintainer like feature requests wey no follow your project plan or person wey dey disturb discussion.
-### Make the chitchat dey friendly
+### Make the talk-talk dey friendly
One important place wey you go practice how to talk no be yes na for your issue and pull request queue. As person wey dey maintain project, e dey natural say you go dey see suggestions wey you no go want accept.
@@ -93,9 +93,9 @@ E better make you quick-close contributions wey you sabi say you no wan accept a
If you no wan accept one contribution:
-* **Thank them** for their contribution
+* **Tell them thank you** for their contribution
* **Explain why e no follow** within the project's scope, and offer clear suggestions for how e fit improve, if you sabi. Make sure say you dey friendly but firm.
-* **Attach link to relevant documentation**, if you get am. If you dey see people dey request the same thing wey you no dey ready to accept, put am for your documentation so that you no go dey repeat yourself.
+* **Link waeh get Relevant documentation na him you go add**, if you get am. If you dey see people dey request the same thing wey you no dey ready to accept, put am for your documentation so that you no go dey repeat yourself.
* **Close the request**
You no need talk pass 1-2 sentences for response. For example, when person wey dey use [celery](https://github.com/celery/celery/) report say e get one Windows-related error, @berkerpeksag [reply like this](https://github.com/celery/celery/issues/3383):
@@ -133,17 +133,17 @@ Although e fit seem like say this approach no dey friendly at first, but e dey b
Sometimes, when you talk no, person fit vex or criticize your decision. If their behavior come bad, [take steps to defuse the situation](https://github.com/jonschlinkert/maintainers-guide-to-staying-positive#action-items) or even remove them from your community, if them no dey ready to work together positively.
-### Show Love for Mentorship
+### Dey Show Love for Mentorship
E fit happen say one person for your community dey always submit contributions wey no meet your project standards. E fit dey vex both parties as them dey reject their work every time.
If you see say person dey show interest for your project but e just need small touch, be patient. Make you clear for every situation why their contributions no dey up to the project standards. Try to show them where them fit do better, maybe by working on one small or less complex task, like issue wey dem mark "good first issue," to give them confidence. If you get time, you fit mentor them as them dey do their first contribution, or you find person for your community wey go fit mentor them.
-## Tap into your community
+## Put hand inside your community
You no need to do everything alone. Your project community dey exist for one reason! Even if you no get active community of contributors yet, if plenty people dey use your project, make them help you.
-### Share the workload
+### Make you share the work
If you dey find people wey go fit help, start to ask around.
@@ -167,7 +167,7 @@ If other people dey happy about the project direction, give them access to make
> I write one wiki page wey describe wetin I want and why I want am. For some reason, e shock me as the maintainers begin move the project in that direction! E no always dey exactly how I go do am? Not every time. But e still bring the project close to wetin I write down.
-### Make others build their own solutions
+### Make other pesin build them own solutions
If potential contributor get another idea for your project and e no follow your own idea, you fit encourage am gently to work on their own fork.
@@ -207,7 +207,7 @@ If you add tests, make sure say you explain how them dey work for your CONTRIBUT
-### Use tools to automate basic maintenance tasks
+### Carry tools use am to automate basic maintenance tasks
The good news about maintaining a popular project be say other maintainers fit don face similar challenges and build solutions for them.
diff --git a/_articles/pidgin/building-community.md b/_articles/pidgin/building-community.md
new file mode 100644
index 00000000000..315c2037cd2
--- /dev/null
+++ b/_articles/pidgin/building-community.md
@@ -0,0 +1,258 @@
+---
+lang: pidgin
+title: Na Welcoming Communities we go Build
+description: Make you build one community wey go encourage people make them use, contribute, and promote your project.
+class: building
+order: 4
+image: /assets/images/cards/building.png
+related:
+ - best-practices
+ - coc
+---
+
+## Set that your project make aeh succeed
+
+You don launch your project, you dey spread the word, and people dey check am out. Correct! Now, how you wan make them stick around?
+
+One welcoming community na one investment into your project's future and reputation. If your project just dey start to see its first contributions, make you start by dey give early contributors one positive experience, and make you dey easy for them to dey come back.
+
+### Make people dey feel welcome
+
+One way to think about your project's community na through wetin @MikeMcQuaid call the [contributor funnel](https://mikemcquaid.com/2018/08/14/the-open-source-contributor-funnel-why-people-dont-contribute-to-your-open-source-project/):
+
+
+
+As you dey build your community, consider how person wey dey the top of the funnel (potential user) fit possibly waka reach the bottom (active maintainer). Your koko na to reduce any wahala for each stage of the contributor experience. Na when people fit see better results without too much stress, them go feel encouraged to do more.
+
+Start with your documentation:
+
+* **Make am easy for person to use your project.** [One friendly README](../starting-a-project/#writing-a-readme) and clear code examples fit make am easier for anybody wey land for your project to begin.
+* **Explain contribution make aeh clear**, using [your CONTRIBUTING file](../starting-a-project/#writing-your-contributing-guidelines) and make sure say your issues dey up-to-date.
+* **Good first issues**: To helep tear rubber contributors start, think am say [labeling issues wey dey simple for beginners to handle](https://help.github.com/en/articles/helping-new-contributors-find-your-project-with-labels). GitHub go show these issues for different places for the platform, e go increase useful contributions and reduce friction for people wey wan handle issues wey too hard for their level.
+
+[GitHub's 2017 Open Source Survey](http://opensourcesurvey.org/2017/) talk say incomplete or confusing documentation na the biggest problem wey open source users dey face. Good documentation go invite people to interact with your project. E fit happen say one person go open an issue or pull request. Use these interactions as opportunities to waka them down the funnel.
+
+* **When new person land for your project, thank them for their interest!** E fit just take one bad experience for person to no wan come back again.
+* **Be responsive.** If you no respond to their issue for one month, e possible say them don forget your project.
+* **Open mind about the types of contributions wey you go accept.** Many contributors start with one bug report or one small fix. Many ways dey to contribute to one project. Make people fit help the way wey them wan help.
+* **If one person submit one contribution wey you no gree with,** thank them for their idea and [explain why](../best-practices/#learning-to-say-no) e no follow your project scope, and you fit add link to the relevant documentation wey you get.
+
+
+
+Most open source contributors na "casual contributors": people wey only occasionally contribute to one project. One casual contributor fit no get time to sabi everything about your project, so your work na to make am easy for them to contribute.
+
+Encouraging other contributors na one investment in yourself, too. When you empower your biggest fans to run with the work wey dem dey passionate about, e go reduce the pressure to dey do everything yourself.
+
+### Make you write everything for document
+
+
+
+When you start one new project, e fit be like say e natural to dey keep your work private. But open source projects dey flourish when you document your process for public.
+
+When you write things down, more people fit participate at every stage of the way. You fit get help for something wey you never sabi say you need am.
+
+To write things down no mean only technical documentation. Anytime you feel the urge to write something down or privately discuss your project, ask yourself whether you fit make am public.
+
+Make you transparent about your project's roadmap, the types of contributions wey you dey look for, how contributions dey review, or why you make certain decisions.
+
+If you see say many people dey run into the same problem, make you document the answers for the README.
+
+For meetings, consider say make you publish your notes or key points for one relevant issue. The feedback wey you go get from this level of transparency fit surprise you.
+
+To document everything apply to the work wey you dey do, too. If you dey work on one substantial update for your project, make you put am for one pull request and mark am as one work in progress (WIP). So, other people fit dey involved for the process from the beginning.
+
+### Be responsive
+
+As you [promote your project](../finding-users), people fit get feedback for you. Them fit get questions about how things dey work, or them fit need help to begin.
+
+Try to dey responsive when person open one issue, submit one pull request, or ask question about your project. When you respond quick, people go feel say them dey part of one discussion, and them go dey more enthusiastic about participation.
+
+Even if you no fit review the request immediately, acknowledge am early to help increase engagement. @tdreyno respond to one pull request for [Middleman](https://github.com/middleman/middleman/pull/1466) like this:
+
+
+
+A Mozilla study talk say if dem review code within 48 hours, plenty contributors dey return and contribute again.
+
+Any talku talku about your project fit dey happen for other places online like Stack Overflow, Twitter, or Reddit. You fit set notification for some of these places so dem go alert you if person talk about your project.
+
+### Make you create one place where your community go gather
+
+E get two reason why you suppose create community place. The first reason na for dem, e go helep dem know each other. People wey get common interest must dey find place wey dem go yan about am. And when communication dey public and easy to reach, anybody fit read past messages make e understand wetin dey happen and fit join the talk. The second reason na for you. If you no create public place for people to discuss your project, dem fit contact you directly. For beginning e fit dey easy for you to respond to private messages "just this once". But as time dey go, especially if your project dey popular, you go dey tire. No gree make you dey communicate with people about your project for private. Instead, direct dem go one public place.
+
+Public communication fit be as simple as directing people make dem go open issue instead of sending mail give you directly or make dem comment for your blog. You fit also create mailing list, or make you create Twitter account, Slack, or IRC channel for people to talk about your project. Or you fit even try all of them!
+
+[Kubernetes kops] (https://github.com/kubernetes/kops#getting-involved) "Kubernetes kops dey set time every other week make dem helep community members:
+
+> Kops still get time wey dem set aside every other week to offer guidance and help to the community. Kops maintainers don agree to set time wey dem go use work with newcomers, helep with PRs, and yan about new features.
+
+Notable exceptions to public communication be: 1) security issues and 2) sensitive code of conduct violations. You suppose always get one way wey people fit report these issues for private. If you no wan use your personal email, set up one email wey dem go use just for this.
+
+## Make your community dey climb
+
+Communities get power. That power fit be good thing or bad thing, depending on how you use am. As your project community dey grow, there dey ways wey you fit use make am be force for building, no be destruction.
+
+### No dey tolerate bad actors
+
+Any popular project go always attract people wey go dey do bad things instead of helep. Dem fit dey start arguments wey no dey necessary, dey quarrel on top small-small things, or dey bully others.
+
+Do your best make you get zero-tolerance policy for these kind people. If you no fit control dem, these bad people fit dey make others for your community no dey comfortable. Dem fit even run.
+
+
+
+Regular debates on top small-small parts of your project dey distract others, and even you, from focusing on important work. New people wey show for your project fit see these arguments and no wan join.
+
+Any time you see bad behavior wey dey happen for your project, yan am out for public. Explain, with kind but firm words, why their behavior no good. If the problem no stop, you fit need [tell them make dem waka](../code-of-conduct/#enforcing-your-code-of-conduct). Your [code of conduct](../code-of-conduct/) fit be useful guide for these talks.
+
+### Meet contributors where dem dey
+
+Good documentation dey very important as your community dey grow. People wey no dey familiar with your project fit read your documentation make dem quickly understand wetin dey happen.
+
+In your CONTRIBUTING file, tell new contributors explicitly how dem go take start. You fit even make one special section for this purpose. [Django](https://github.com/django/django), for example, get one special landing page to welcome new contributors.
+
+
+
+For your issue queue, label bugs wey dey suitable for different types of contributors, like [_"first timers only"_](https://kentcdodds.com/blog/first-timers-only), _"good first issue"_, or _"documentation"_. [These labels](https://github.com/librariesio/libraries.io/blob/6afea1a3354aef4672d9b3a9fc4cc308d60020c8/app/models/github_issue.rb#L8-L14) These labels go helep someone wey dey new to your project to easily look your issues and take start.
+
+Use your documentation to helep people feel welcome at every step.
+
+For example, here's how [Rubinius](https://github.com/rubinius/rubinius/) starts [its contributing guide](https://github.com/rubinius/rubinius/blob/HEAD/.github/contributing.md):
+
+You no go fit talk with most people wey go show for your project. Some people fit come helep you wey you no go sabi because dem feel say dem dey intimidated or dem no sabi where to take start. Even few kind words fit helep make person no commot for your project for frustration.
+
+### Share the person waeh get your project
+
+
+
+People dey ginger to yan-kick for projects when dem feel like dem get sense of ownership. E no mean say you go come give dem your project vision or gree accept contributions wey you no want. But as you dey respect and appreciate other people efforts, e go make dem dey yan-kick.
+
+Try look for ways wey you fit share this ownership with your community as much as possible. Some yeye ideas wey you fit try include:
+
+* **No dey hurry to fix small-small (non-serious) wahala.** Instead, use am as chance to bring new contributors or show person way wan yan-kick. E fit look strange at first, but as time go dey, your investment go bring profit. For example, @michaeljoseph tell one person say make e submit pull request for [Cookiecutter](https://github.com/audreyr/cookiecutter) issue for down, instead of make e fix am himself.
+
+
+
+* **Start CONTRIBUTORS or AUTHORS file for your project** wey go list everybody wey don yan-kick for your project, like [Sinatra](https://github.com/sinatra/sinatra/blob/HEAD/AUTHORS.md) do.
+
+* If your community don shapely well-well, **send newsletter or write blog post** to appreciate the people wey don yan-kick. Rust's [This Week in Rust](https://this-week-in-rust.org/) and Hoodie's [Shoutouts](http://hood.ie/blog/shoutouts-week-24.html) na two examples wey dey good.
+
+* **Give every contributor access to commit.** @felixge see say this one dey ginger people, e make dem dey shine their patches [more](https://felixge.de/2013/03/11/the-pull-request-hack.html), and e even find new maintainers for projects wey e never dey touch for long.
+
+* If your project dey on GitHub, **move your project from your personal account go [Organization](https://help.github.com/articles/creating-a-new-organization-account/)** and add at least one backup admin. Organizations dey make am easy to work with external people.
+
+The fact na say [most projects get](https://peerj.com/preprints/1233/) only one or two maintainers wey dey do plenty work. As your project dey grow or your community dey big pass, e go dey easy to find help.
+
+Even if you no fit always find person to answer the call, once you put signal for there, e dey increase chance say other people go waka come yan-kick. The earlier you start, the better for you, because e go make people waka come fast-fast.
+
+Na for [Welcoming Communities](http://hood.ie/blog/welcoming-communities.html), @gr2m yarn say e dey for your [best interest](https://peerj.com/preprints/1233/) to find contributors wey sabi and enjoy to do the things wey you no sabi. If you like code but e no dey easy for you to answer issues, try find people for your community wey sabi, make dem handle am.
+
+## Settling Wahala
+
+As your project dey begin, e dey easy to make major decisions. When you wan do something, e fit be like breeze, you go just do am.
+
+As your project dey popular, more people go dey chook eye for the decisions wey you dey take. Even if you no get big community of contributors, if your project get many users, people go wan add their mouth for the decisions or raise their own issues.
+
+Aside small-small issues wey e clear say your community go fit resolve, sometimes you fit see say one issue dey tough small small.
+
+### Arrange everything make kindness dey
+
+When your community dey tackle one yeye issue, tempers fit dey rise. People fit vex or feel frustrated and dem fit they chook mouth for each other or for your matter.
+
+Your work as maintainer na to make sure say these situations no go high. Even if you get strong opinion on top the matter, try play moderator or facilitator role, no just enter the matter dey force your views. If person no dey polite or e dey use mouth scatter discussions, [take action immediately](../building-community/#dont-tolerate-bad-actors) to make sure say discussions dey civil and productive.
+
+Other people dey look you for guidance. Set example wey go make sense. You fit still yan your disappointment, sorrow or concern, but do am calmly.
+
+Make your head nor dey hot e nor easy, but as you set good example, e go make your community strong. The internet dey thank you.
+
+### Treat README like say na constitution
+
+Your README [no be only set of instructions](../starting-a-project/#writing-a-readme). E also na place to yan about your goals, product vision, and roadmap. If people dey focus too much on top argument about one particular feature, e fit help if you go back your README, talk about the higher vision of your project. To focus on your README go even make the matter no dey personal, so that you go fit yan-kick with sense.
+
+
+### Make we focus for the journey, nor be the destination
+
+Some projects dey use voting process to take make major decisions. E fit look sensible for eye at first, but voting dey show say them dey find 'answer,' instead of say them dey listen to each other concerns.
+
+Voting fit turn political, where people for the community go dey fear say them go gree do favors for each other or vote in one particular way. Nor be everybody go fit vote, whether e na the [silent majority](https://ben.balter.com/2016/03/08/optimizing-for-power-users-and-edge-cases/#the-silent-majority-of-users) for your community or people wey dey use your project wey nor know say vote dey happen.
+
+Sometimes, voting na necessary way to take settle wahala. But as much as you fit, try dey emphasize ["consensus seeking"](https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) instead of consensus.
+
+For one consensus seeking process, community members go yan about major concerns until them believe say their talk don dey enough. When only small-small concerns still dey, the community go dey go front. "Consensus seeking" no dey expect say the community go reach perfect answer. Instead, e dey focus on listening and discussion.
+
+
+
+Even if you nor actually use consensus seeking process, as a project maintainer, e dey important make people know say you dey hear them. To show say you dey hear people and you dey ready to settle their wahala, e dey help to cool down tense situations. After that, follow your words with actions.
+
+Don't dey rush make you take decision just because you wan find solution. Try make everybody feel say dem don dey hear and all information dey public before you fit find solution.
+
+### Make we dey yan for action
+
+Discussion dey important, but difference dey between productive and unproductive talks.
+
+Encourage discussion as long as e dey carry us close to solution. If e clear say the talk dey delay or dem dey yan out of the matter or e dey like say dem dey yan personal talk, or people dey yan yeye about small details, e dey time to stop am.
+
+If you allow this kind talk to continue, e no go only bad for the issue wey dey ground, e go dey bad for the health of your community. E go show say this kind talk na normal thing wey them dey allow or even dey encourage, and e fit discourage people from raising or settling future issues.
+
+For every talk wey you talk or other people talk, ask yourself, _"How this one wan carry us closer to solution?
+
+If the talk dey scatter, make you ask the group, _"Which steps we wan take next?"_ to refocus the discussion.
+
+If the talk clear nor dey waka, e nor get clear action to take, or the right action don already happen, close the issue and yan why you close am.
+
+
+
+
+### Choose your battles with sense
+
+Context dey important. Think about the people wey dey the discussion and how them represent the rest of the community.
+
+Na all the community dey vex or even follow for this issue? Or na just one person wey wan dey find trouble? No forget say you suppose consider your silent community members, nor be only the people wey dey yan.
+
+If the issue nor dey show the real needs of your community, you fit just gree say the concerns of few people matter. If this one na issue wey dey always come up and nor dey get clear solution, tell them say make them check discussions wey dem don already talk about the matter before and close the discussion.
+
+### Identify person or group wey fit be community tiebreaker
+
+With correct attitude and clear communication, many difficult situations fit dey easy to settle. But even for productive talk, e fit still dey difference for opinion on how to dey move front. For this kind situation, identify one person or group of people wey fit help settle the wahala.
+
+One tiebreaker fit be the main person wey dey control the project, or e fit be small group of people wey fit make decision based on voting. E good make you don already identify tiebreaker and the process for GOVERNANCE file before e go happen.
+
+Your tiebreaker suppose be last option. Issues wey dey cause fight for community dey make the community fit grow and learn. Embrace the opportunity and use collaborative process to find solution where you fit.
+
+## Community na the ❤️ of open source
+
+Healthy and vibrant communities na the engine wey dey fuel the plenty hours wey dem spend for open source every week. Many contributors dey point to other people as the reason why dem dey work - or nor dey work - for open source. As you sabi tap into that power constructively, you go fit help person somewhere get unforgettable open source experience.
diff --git a/_articles/pidgin/code-of-conduct.md b/_articles/pidgin/code-of-conduct.md
new file mode 100644
index 00000000000..6ed301d9c81
--- /dev/null
+++ b/_articles/pidgin/code-of-conduct.md
@@ -0,0 +1,58 @@
+---
+lang: pidgin
+title: Una Code of Conduct
+description: Make community people dey behave well and do constructive tins, by accepting and enforcing the code of conduct.
+class: coc
+order: 8
+image: /assets/images/cards/coc.png
+related:
+ - building
+ - leadership
+---
+
+## Code of conduct and why you need am?
+
+Code of conduct na document wey dey establish expectation for the way wey people go take behave for your project. To adopt, and enforce, code of conduct fit help create positive social atmosphere for your community.
+
+Code of conduct epp to protect not just the people wey dey participate for your project, but you too. If you dey maintain a project, you fit see say unproductive attitude from other people fit dey drain your energy and make you unhappy about your work as time dey go.
+
+Code of conduct dey give you power to encourage healthy and constructive community behavior. To dey proactive dey reduce the chance say you, or other people, go dey tire for your project, and epp you take action if person do something wey you nor gree with.
+
+## How you go take arrange code of conduct
+
+Make you try your best to arrange code of conduct early, if you fit, ideally when you first create your project.
+
+Apart from just communicating your expectations, code of conduct fit describe the following:
+
+- Where the code of conduct dey apply _(only on issues and pull requests, or community activities like events?)_
+- Whom the code of conduct dey apply to _(community members and maintainers, but what about sponsors?)_
+- Wetin go happen if person violate the code of conduct
+- How person fit report violations
+
+Anywhere way you fit, try to use previous example. The [Contributor Covenant](https://contributor-covenant.org/) na code of conduct wey many open source projects, including Kubernetes, Rails, and Swift, don use, and e fit serve as example.
+
+The [Django Code of Conduct](https://www.djangoproject.com/conduct/) and the [Citizen Code of Conduct](https://web.archive.org/web/20200330154000/http://citizencodeofconduct.org/) na two good examples of code of conduct.
+
+Put one CODE_OF_CONDUCT file for your project's main directory, and make sure say your community fit see am by linking am for your CONTRIBUTING or README file.
+
+## How to enforce your code of conduct
+
+You suppose explain how you go enforce your code of conduct **_before_** person violate am. Some reasons why you suppose do am be say:
+
+- E show say you dey serious about action when e dey necessary.
+
+- Your community go dey reassured say complaints go dey reviewed.
+
+- You go reassure your community say the review process go dey fair and transparent, if at any time dem dey investigated for violation.
+
+You suppose give people private way (like email address) to report code of conduct violation and explain who go receive that report. E fit be maintainer, group of maintainers, or code of conduct working group.
+
+No forget say person fit wan report violation about person wey dey receive those reports. In this case, give dem option to report violations to another person. For example, @ctb and @mr-c [explain for their project](https://github.com/dib-lab/khmer/blob/HEAD/CODE_OF_CONDUCT.rst), [khmer](https://github.com/dib-lab/khmer):
+
+> Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by emailing **khmer-project@idyll.org** which only goes to C. Titus Brown and Michael R. Crusoe. To report an issue involving either of them please email **Judi Brown Clarke, Ph.D.** the Diversity Director at the BEACON Center for the Study of Evolution in Action, an NSF Center for Science and Technology.
+
+For inspiration, check out Django's [enforcement manual](https://www.djangoproject.com/conduct/enforcement-manual/) (though you may not need something this comprehensive, depending on the size of your project).
+
+## How to enforce your code of conduct
+
+Sometimes, despite your best efforts, somebody go do something wey dey violate this code. There are several ways to address negative or harmful behavior when it comes up.
diff --git a/_data/locales/pidgin.yml b/_data/locales/pidgin.yml
new file mode 100644
index 00000000000..7a6a648f6dd
--- /dev/null
+++ b/_data/locales/pidgin.yml
@@ -0,0 +1,31 @@
+en:
+ locale_name: English
+ nav:
+ about: About
+ contribute: Put hand
+ index:
+ lead: Open source software na people wey dey like you epp build am. Learn how to start and make your project big.
+ opensourcefriday: Na Friday! Spend few hours to contribute to the software wey you dey use and love.
+ article:
+ table_of_contents: Table of Contents
+ back_to_all_guides: Abeg, make I run go back to all those guides
+ related_guides: Related Guides
+ footer:
+ contribute:
+ heading: Put hand
+ description: You wan yan something? This mata wey dey here, e fit be your own. Abeg, helep us make e better.
+ button: Put hand
+ subscribe:
+ heading: Make we dey in contact
+ description: Make you be the first wey go hear about GitHub's latest open source tips and resources..
+ label: Email adiress
+ button: Folow
+ byline:
+ # [code], [love], and [github] will be replaced by octicons
+ format: "[code] with [love] by [github] and [friends]"
+ # Label for code octicon
+ code_label: code
+ # Label for love octicon
+ love_label: love
+ # Label for the contributors link
+ friends_label: padi
diff --git a/assets/css/translate.scss b/assets/css/translate.scss
index d8403e141b2..98c0508c3c9 100644
--- a/assets/css/translate.scss
+++ b/assets/css/translate.scss
@@ -26,6 +26,7 @@ $section_translation: (
"tr": "",
"zh-hant": "章節",
"zh-hans": "章节",
+ "pidgin": "Portion",
);
@each $locale, $translation in $section_translation {