Skip to content

TL Localization - Chapter 6, section 2 - part 1 (1,146 words) #19

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Feb 11, 2018
Merged

TL Localization - Chapter 6, section 2 - part 1 (1,146 words) #19

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
6872d6d
TL translation for 2-contributing.asc (part 1)
heywens Feb 11, 2018
dbf7b18
applied changes based on reviewer's suggestions
heywens Feb 11, 2018
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
164 changes: 82 additions & 82 deletions book/06-github/sections/2-contributing.asc
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,78 +1,78 @@
=== Contributing to a Project
=== Pag-aambag sa isang Proyekto

Now that our account is set up, let's walk through some details that could be useful in helping you contribute to an existing project.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

kindly change na-setup to na-set up ?

As setup is a noun and set up is a verb :)

Ngayon na na-set up na ang ating account, tingnan natin ang ilang mga detalye na maaaring kapaki-pakinabang sa pagtulong sa iyo na mag-ambag sa isang umiiral na proyekto.

==== Forking Projects
==== Pag-fork ng mga Proyekto

(((forking)))
If you want to contribute to an existing project to which you don’t have push access, you can ``fork'' the project.
When you ``fork'' a project, GitHub will make a copy of the project that is entirely yours; it lives in your namespace, and you can push to it.
Kung gusto mong mag-ambag sa isang umiiral na proyekto na wala kang access sa pag-push, maaari kang mag-``fork'' sa proyekto.
Kapag ikaw ay nag-``fork'' ng isang proyekto, gagawan ka ng GitHub ng kopya sa proyekto na ganap na sa iyo; ito ay nasa iyong namespace, at maaari kang mag-push dito.

[NOTE]
[TANDAAN]
====
Historically, the term ``fork'' has been somewhat negative in context, meaning that someone took an open source project in a different direction, sometimes creating a competing project and splitting the contributors.
In GitHub, a ``fork'' is simply the same project in your own namespace, allowing you to make changes to a project publicly as a way to contribute in a more open manner.
Sa kasaysayan, ang termino na ``fork'' ay medyo negatibo sa konteksto, ibig sabihin na may kumuha sa isang open-source na proyekto sa isang ibang direksiyon, na minsan ay lumilikha ng pakikipagkumpitensya sa proyekto at paghahati sa mga nag-aambag.
Sa GitHub, ang ``fork'' ay ang parehong proyekto lamang sa iyong sariling namespace, nagbibigay-daan sa iyo na pampublikong gumawa ng mga pagbabago sa isang proyekto bilang isang paraan na mag-ambag sa isang mas bukas na pamamaraan.
====

This way, projects don’t have to worry about adding users as collaborators to give them push access.
People can fork a project, push to it, and contribute their changes back to the original repository by creating what's called a Pull Request, which we'll cover next.
This opens up a discussion thread with code review, and the owner and the contributor can then communicate about the change until the owner is happy with it, at which point the owner can merge it in.
Sa paraang ito, hindi na kailangan mag-alala ng mga proyekto tungkol sa pagdagdag ng mga user bilang mga tagatulong na bigyan sila ng access sa pag-push.
Maaari mag-force ang mga tao sa isang proyekto, mag-push dito, at mag-ambag sa kanilang mga pagbabago pabalik sa kanilang orihinal na repositoryo sa pamamagitan ng paglilikha ng tinatawag na Kahilingan na Pull, na ating itatalakay sa susunod.
Ito ay nagbubukas ng isang thread ng diskusyon sa pagsusuri ng code, at ang may-ari at nag-aambag ay maaari makikipag-usap tungkol sa pagbabago hanggang ang may-ari ay masaya dito, kung saan ang may-ari ay maaaring pagsamahin ito.

To fork a project, visit the project page and click the ``Fork'' button at the top-right of the page.
Para ma-fork ang isang proyekto, bisitahin ang pahina ng proyekto at i-click ang pindutan na ``Fork'' na nasa kanang itaas ng pahina.

.The ``Fork'' button.
image::images/forkbutton.png[The ``Fork'' button.]
.Ang ``Fork'' na pindutan.
image::images/forkbutton.png[Ang ``Fork'' na pindutan.]

After a few seconds, you'll be taken to your new project page, with your own writeable copy of the code.
Pagkatapos ng ilang segundo, dadalhin ka sa pahina ng iyong bagong proyekto, na may sariling kopya ng code na maaaring mabago.


[[_github_flow]]
==== The GitHub Flow
==== Ang Daloy ng GitHub

(((GitHub, Flow)))
GitHub is designed around a particular collaboration workflow, centered on Pull Requests.
This flow works whether you're collaborating with a tightly-knit team in a single shared repository, or a globally-distributed company or network of strangers contributing to a project through dozens of forks.
It is centered on the <<_git_branching#_topic_branch>> workflow covered in <<_git_branching#_git_branching>>.
Ang GitHub ay dinisenyo sa paligid ng isang partikular na workflow sa pakikipagtulungan, nakasentro sa mga Kahilingan na Pull.
Ang daloy na ito ay gumagana kung nakikipagtulungan ka sa isang mahigpit na pangkat sa isang solong ibinahaging repositoryo, o isang kompanyang ibinahagi sa mundo o network ng mga estranghero na nag-aambag sa isang proyekto sa pamamagitan ng dose-dosenang mga fork.
Ito ay nakasentro sa workflow na <<_git_branching#_topic_branch>> na tinalakay sa <<_git_branching#_git_branching>>.

Here's how it generally works:
Narito kung paano ito gumagana:

1. Fork the project
2. Create a topic branch from `master`.
3. Make some commits to improve the project.
4. Push this branch to your GitHub project.
5. Open a Pull Request on GitHub.
6. Discuss, and optionally continue committing.
7. The project owner merges or closes the Pull Request.
1. I-fork ang proyekto
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Magbukas ng isang Kahilingan ng Pull sa GitHub. to Magbukas ng isang Pull na Kahilingan sa GitHub.

2. Lumikha ng isang branch ng paksa mula sa `master`.
3. Gumawa ng ilang commits upang mapabuti ang proyekto.
4. I-push ang branch na ito sa iyong proyekto sa GitHub.
5. Magbukas ng isang Kahilingan na Pull sa GitHub.
6. Talakayin, at opsyonal na patuloy na gumawa.
7. Pagsasamahin o isasara ng may-ari ng proyekto ang Kahilingan na Pull.

This is basically the Integration Manager workflow covered in <<_distributed_git#_integration_manager>>, but instead of using email to communicate and review changes, teams use GitHub's web based tools.
Ito ang karaniwan na workflow ng Tagapamahala ng Paglagom na tinalakay sa <<_distributed_git#_integration_manager>>, ngunit sa halip na gagamit ng email sa pakikipag-ugnayan at pagsusuri ng mga pagbabago, ang pangkat ay gumagamit ng mga kagamitan ng GitHub na nakabatay sa web.

Let's walk through an example of proposing a change to an open source project hosted on GitHub using this flow.
Talakayin natin ang isang halimbawa ng pagpapanukala ng pagbabago sa isang open-source na proyekto na naka-host sa GitHub gamit ang daloy na ito.

===== Creating a Pull Request
===== Paglilikha ng isang Kahilingan na Pull

Tony is looking for code to run on his Arduino programmable microcontroller and has found a great program file on GitHub at https://github.com/schacon/blink[].
Naghahanap ng code si Tony na tatakbo sa kanyang Arduino programmable microcontroller at nakatagpo ng isang mahusay na file ng programa sa GitHub sa https://github.com/schacon/blink[].

.The project we want to contribute to.
image::images/blink-01-start.png[The project we want to contribute to.]
.Ang proyekto na gusto nating tulungan.
image::images/blink-01-start.png[Ang proyekto na gusto nating tulungan.]

The only problem is that the blinking rate is too fast, we think it's much nicer to wait 3 seconds instead of 1 in between each state change.
So let's improve the program and submit it back to the project as a proposed change.
Ang tanging problema ay ang masyadong mabilis ang kumukurap na rate, sa tingin namin ito ay mas mahusay na maghintay ng 3 segundo sa halip ng 1 sa pagitan ng bawat pagbabago ng estado.
Kaya ating pabutihin ang programa at isumite ito pabalik sa proyekto bilang isang iminungkahing pagbabago.

First, we click the 'Fork' button as mentioned earlier to get our own copy of the project.
Our user name here is ``tonychacon'' so our copy of this project is at `https://github.com/tonychacon/blink` and that's where we can edit it.
We will clone it locally, create a topic branch, make the code change and finally push that change back up to GitHub.
Una, ating i-click ang pindutan na 'Fork' tulad ng nabanggit kanina upang makuha ang ating sariling kopya ng proyekto.
Ang pangalan ng gumagamit dito ay ``tonychacon'' kaya ang kopya ng ating proyekto ay nasa `https://github.com/tonychacon/blink` at diyan natin maaaring mabago ito.
Atin itong lokal na i-clone, lumikha ng isang branch ng paksa, gumawa ng pagbabago sa code at sa wakas ay i-push ang pagbabago na iyon pabalik sa GitHub.

[source,console]
----
$ git clone https://github.com/tonychacon/blink <1>
Cloning into 'blink'...
Nagko-clone sa 'blink'...

$ cd blink
$ git checkout -b slow-blink <2>
Switched to a new branch 'slow-blink'
Lumipat sa isang bagong branch na 'slow-blink'

$ sed -i '' 's/1000/3000/' blink.ino (macOS) <3>
# If you're on a Linux system, do this instead:
# Kung ikaw ay nasa isang sistema na Linux, gawin ito sa halip:
# $ sed -i 's/1000/3000/' blink.ino <3>

$ git diff --word-diff <4>
Expand All @@ -81,73 +81,73 @@ index 15b9911..a6cc5a5 100644
--- a/blink.ino
+++ b/blink.ino
@@ -18,7 +18,7 @@ void setup() {
// the loop routine runs over and over again forever:
// ang loop na gawain ay tumatakbo nang paulit-ulit magpakailanman:
void loop() {
digitalWrite(led, HIGH); // turn the LED on (HIGH is the voltage level)
[-delay(1000);-]{+delay(3000);+} // wait for a second
digitalWrite(led, LOW); // turn the LED off by making the voltage LOW
[-delay(1000);-]{+delay(3000);+} // wait for a second
digitalWrite(led, HIGH); // i-on ang LED (HIGH ay ang antas ng boltahe)
[-delay(1000);-]{+delay(3000);+} // maghintay ng isang segundo
digitalWrite(led, LOW); // i-off ang LED sa pamamagitan ng paggawa ng boltahe sa LOW
[-delay(1000);-]{+delay(3000);+} // maghintay ng isang segundo
}

$ git commit -a -m 'three seconds is better' <5>
[slow-blink 5ca509d] three seconds is better
1 file changed, 2 insertions(+), 2 deletions(-)
$ git commit -a -m 'mas mahusay ang tatlong segundo' <5>
[slow-blink 5ca509d] mas mahusay ang tatlong segundo
1 file ang nabago, 2 pagsisingit(+), 2 pagtatanggal(-)

$ git push origin slow-blink <6>
Username for 'https://github.com': tonychacon
Password for 'https://tonychacon@github.com':
Counting objects: 5, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 340 bytes | 0 bytes/s, done.
Total 3 (delta 1), reused 0 (delta 0)
To https://github.com/tonychacon/blink
Username para sa 'https://github.com': tonychacon
Password para sa 'https://tonychacon@github.com':
Pagbibilang ng mga bagay: 5, tapos na.
Delta compression na gumagamit ng hanggang 8 threads.
Nagko-compress ng mga bagay: 100% (3/3), tapos na.
Nagsusulat ng mga bagay: 100% (3/3), 340 bytes | 0 bytes/s, tapos na.
Kabuuan 3 (delta 1), muling nagamit 0 (delta 0)
Sa https://github.com/tonychacon/blink
* [new branch] slow-blink -> slow-blink
----

<1> Clone our fork of the project locally
<2> Create a descriptive topic branch
<3> Make our change to the code
<4> Check that the change is good
<5> Commit our change to the topic branch
<6> Push our new topic branch back up to our GitHub fork
<1> I-clone nang pa-lokal ang ating fork sa proyekto
<2> Lumikha ng isang mapaglarawang branch ng paksa
<3> Gawin ang ating pagbabago sa code
<4> Suriin na ang pagbabago ay mabuti
<5> I-commit ang ating pagbabago sa branch ng paksa
<6> I-push ang ating bagong branch ng paksa pabalik sa ating fork sa GitHub

Now if we go back to our fork on GitHub, we can see that GitHub noticed that we pushed a new topic branch up and presents us with a big green button to check out our changes and open a Pull Request to the original project.
Ngayon kung tayo ay babalik sa ating fork sa GitHub, makikita natin na napansin ng GitHub na tayo ay nag-push ng isang bagong branch ng paksa at nagtatanghal sa atin ng isang malaking berdeng pindutan upang suriin ang ating mga pagbabago at magbukas ng isang Kahilingan na Pull sa orihinal na proyekto.

You can alternatively go to the ``Branches'' page at `https://github.com/<user>/<project>/branches` to locate your branch and open a new Pull Request from there.
Maaari kang pumunta sa pahina ng ``Branches'' sa `https://github.com/<user>/<project>/branches` upang hanapin ang iyong branch at magbukas ng isang bagong Kahilingan na Pull mula doon.

.Pull Request button
image::images/blink-02-pr.png[Pull Request button]
.Pindutan na Kahilingan na Pull
image::images/blink-02-pr.png[Pindutan na Kahilingan na Pull]

(((GitHub, pull requests)))
If we click that green button, we'll see a screen that asks us to give our Pull Request a title and description.
It is almost always worthwhile to put some effort into this, since a good description helps the owner of the original project determine what you were trying to do, whether your proposed changes are correct, and whether accepting the changes would improve the original project.
Kung i-click natin ang berdeng pindutan na iyon, makikita natin ang isang screen na nagtatanong sa atin na magbigay ng titulo at paglalarawan sa ating Kahilingan na Pull.
Ito ay halos palaging kapaki-pakibanang na maglagay ng ilang pagsisikap dito, dahil ang isang mahusay na paglalarawan ay nakakatulong sa may-ari ng orihinal na proyekto na matukoy ang anumang sinubukan mong gawin, kung ang iminungkahing pagbabago ay tama, o kung ang pagtatanggap ng mga pagbabago ay makakabuti sa orihinal na proyekto.

We also see a list of the commits in our topic branch that are ``ahead'' of the `master` branch (in this case, just the one) and a unified diff of all the changes that will be made should this branch get merged by the project owner.
Nakikita rin natin ang isang listahan ng mga gumawa sa ating branch ng paksa na ``ahead'' sa ating branch na `master` (sa kasong ito, isa lamang) at ang isang pinag-isang diff sa lahat ng mga pagbabago na gagawin kung dapat bang ang branch na ito ay isama ng may-ari ng proyekto.

.Pull Request creation page
image::images/blink-03-pull-request-open.png[Pull Request creation]
.Pahina ng paglilikha ng Kahilingan na Pull
image::images/blink-03-pull-request-open.png[Pahina ng paglilikha ng Kahilingan na Pull]

When you hit the 'Create pull request' button on this screen, the owner of the project you forked will get a notification that someone is suggesting a change and will link to a page that has all of this information on it.
Kapag pinindot mo ang pindutan na 'Lumikha ng kahilingan na pull', ang may-ari ng proyekto na iyong na-fork ay makakakuha ng abiso na may nagmumungkahi ng isang pagbabago at magli-link sa isang pahina kung saan naroon ang lahat ng mga impormasyon na ito.

[NOTE]
[TANDAAN]
====
Though Pull Requests are used commonly for public projects like this when the contributor has a complete change ready to be made, it's also often used in internal projects _at the beginning_ of the development cycle. Since you can keep pushing to the topic branch even *after* the Pull Request is opened, it's often opened early and used as a way to iterate on work as a team within a context, rather than opened at the very end of the process.
Kahit ang mga Kahilingan na Pull ay pangkaraniwan na ginamit para sa mga pampublikong proyekto kagaya nito kung saan ang nag-aambag ay mayroong kumpletong pagbabago na handang gawin, ito rin ay madalas na ginamit sa mga panloob na mga proyekto _sa simula_ ng cycle ng development. Dahil maaari kang patuloy na mag-push sa branch ng paksa kahit 'pagkatapos' na nabuksan ang Kahilingan na Pull, ito'y madalas na nakabukas nang maaga at ginamit bilang isang paraan upang ulitin ang paggawa bilang isang pangkat sa loob ng konteksto, sa halip na buksan sa kaduluhan ng proseso.
====

===== Iterating on a Pull Request
===== Pag-uulit sa Kahilingan na Pull

At this point, the project owner can look at the suggested change and merge it, reject it or comment on it. Let's say that he likes the idea, but would prefer a slightly longer time for the light to be off than on.
Sa puntong ito, ang may-ari ng proyekto ay maaari tumingin sa iminungkahing pagbabago at pagsamahin ito, tanggihan ito o magkomento dito. Sabihin natin na hindi niya gusto ang ideya, ngunit mas gusto ng isang bahagyang mas mahabang oras para sa liwanag na i-off kaysa i-on.

Where this conversation may take place over email in the workflows presented in <<_distributed_git#_distributed_git>>, on GitHub this happens online. The project owner can review the unified diff and leave a comment by clicking on any of the lines.
Kung saan ang pag-uusap na ito ay maaaring maganap sa email sa workflow na ipinakita sa << _ distributed_git # _distributed_git >>, sa GitHub nangyayari ito online. Maaaring suriin ng may-ari ng proyekto ang pinag-isang diff at mag-iwan ng komento sa pamamagitan ng pag-click sa alinman sa mga linya.

.Comment on a specific line of code in a Pull Request
image::images/blink-04-pr-comment.png[PR line comment]
.Magkomento sa isang partikular na linya ng code sa isang Kahilingan na Pull
image::images/blink-04-pr-comment.png[komento sa linya ng PR]

Once the maintainer makes this comment, the person who opened the Pull Request (and indeed, anyone else watching the repository) will get a notification. We'll go over customizing this later, but if he had email notifications turned on, Tony would get an email like this:
Kapag ang tagapangasiwa ay gumagawa ng komentong ito, ang taong nagbukas ng Kahilingan na Pull (at sa katunayan, ang sinumang iba pa na nanonood sa repositoryo) ay makakakuha ng isang abiso. Susubukan nating baguhin ang pagpapasadya na ito sa ibang pagkakataon, ngunit kung mayroon siyang mga abiso sa email na naka-on, makakakuha si Tony ng isang email na katulad nito:

[[_email_notification]]
.Comments sent as email notifications
.Mga komento naipadala bilang mga abiso sa email
image::images/blink-04-email.png[Email notification]

Anyone can also leave general comments on the Pull Request. In <<_pr_discussion>> we can see an example of the project owner both commenting on a line of code and then leaving a general comment in the discussion section. You can see that the code comments are brought into the conversation as well.
Expand Down