TL Localization - Chapter 6, section 2 - part 3 (1,397 words)

book/06-github/sections/2-contributing.asc

@@ -260,160 +260,161 @@ Isa sa mga magagandang bagay tungkol sa Git ay maaari mong patuloy na gawin iyon
 
 Kung talagang gusto mong i-rebase ang branch upang malinis ito, maaari mong tiyak na gawin ito, ngunit ito ay lubos na hinihikayat na huwag piliting mag-push sa branch na ang Kahilingan na Pull ay binuksan na. Kung ang ibang tao ay naka-pull na dito at nakagawa ng mas maraming trabaho, mararanasan mo ang lahat ng isyo na nakabalangkas sa <<_git_branching#_rebase_peril>>. Sa halip, i-push ang branch na naka-rebase sa isang bagong branch sa GitHub at magbukas ng isang bagong Kahilingan na Pull na tumutukoy sa luma, pagkatapos ay isara ang orihinal.
 
-===== References
+===== Mga Reperensiya
 
-Your next question may be ``How do I reference the old Pull Request?''. It turns out there are many, many ways to reference other things almost anywhere you can write in GitHub.
+Ang iyong susunod na tanong ay maaaring ``Paano ko ireperensiya ang lumang Kahilingan na Pull?''. Lumilitaw na mayroong maraming, maraming mga paraan upang magamit ang iba pang mga bagay halos kahit saan maaari kang sumulat sa GitHub.
 
-Let's start with how to cross-reference another Pull Request or an Issue. All Pull Requests and Issues are assigned numbers and they are unique within the project. For example, you can't have Pull Request #3 _and_ Issue #3. If you want to reference any Pull Request or Issue from any other one, you can simply put `#<num>` in any comment or description. You can also be more specific if the Issue or Pull request lives somewhere else; write `username#<num>` if you're referring to an Issue or Pull Request in a fork of the repository you're in, or `username/repo#<num>` to reference something in another repository.
+Simulan natin kung paano magtukoy ng ibang Kahilingan na Pull o isang Isyu. Lahat ng mga Kahilingan na Pull at mga Isyu ay mga nakatalagang numero at ito ay natatangi sa proyekto. Halimbawa, hindi ka maaaring magkaroon ng Kahilingan na Pull #3 _at_ Isyu #3. Kung gusto mong magreperensiya ng anumang Kahilingan na Pull o Isyu mula sa iba pa, maaari mo lamang ilagay ang `#<num>` sa anumang komento o paglalarawan. Maaari ka ring maging mas tiyak kung ang Isyu o ang Kahilingan na Pull ay nabubuhay sa ibang lugar; sumulat ng `username#<num>` kung ikaw ay nagtutukoy ng isang Isyu o Kahilingan na Pull sa isang fork ng repositoryo kung ikaw ay nasaan, o `username/repo#<num>` upang ireperensiya ang ilang bagay sa ibang repositoryo.
 
-Let's look at an example. Say we rebased the branch in the previous example, created a new pull request for it, and now we want to reference the old pull request from the new one. We also want to reference an issue in the fork of the repository and an issue in a completely different project. We can fill out the description just like <<_pr_references>>.
+Tingnan natin ang isang halimbawa. Sabihing ating na-rebase ang branch sa nakaraang halimbawa, naglikha ng isang bagong kahilingan na pull para rito, at ngayon gusto natin na ireperensiya ang lumang kahilingan na pull mula sa bago. Gusto din natin na ireperensiya ang isang isyu sa fork ng repositoryo at isyu sa ganap na naiibang proyekto. Maaari nating punan ang paglalarawan kagaya ng <<_pr_references>>.
 
 [[_pr_references]]
-.Cross references in a Pull Request.
+.Mga Pagtukoy sa isang Kahilingan na Pull.
 image::images/mentions-01-syntax.png[PR references]
 
-When we submit this pull request, we'll see all of that rendered like <<_pr_references_render>>.
+Kapag tayo ay nagsumite ng kahilingan na pull na ito, makikita natin ang lahat ng mga naibigay tulad ng <<_pr_references_render>>.
 
 [[_pr_references_render]]
-.Cross references rendered in a Pull Request.
+.Mga pagtukoy na naibigay sa isang Kahilingan na Pull.
 image::images/mentions-02-render.png[PR references rendered]
 
-Notice that the full GitHub URL we put in there was shortened to just the information needed.
+Pansinin na ang buong URL ng GitHub na ating nilagay doon ay pinaikli sa kailangan lamang na impormasyon.
 
-Now if Tony goes back and closes out the original Pull Request, we can see that by mentioning it in the new one, GitHub has automatically created a trackback event in the Pull Request timeline. This means that anyone who visits this Pull Request and sees that it is closed can easily link back to the one that superseded it. The link will look something like <<_pr_closed>>.
+Ngayon kung babalik si Tony at isasara ang orihinal na Kahilingan na Pull, maaari nating makita na sa pagbabanggit nito sa isang bago, awtomatikong nilikha ng GitHub ang isang trackback event sa timeline ng Kahilingan na Pull. Ito ay nangangahulugan na sinuman ang bibisita sa Kahilingan na Pull na ito at makakakita na ito ay naisara ay maaaring madaling maka-link pabalik sa pumalit nito. Magiging tulad ng <<_pr_closed>> ang link.
 
 [[_pr_closed]]
-.Link back to the new Pull Request in the closed Pull Request timeline.
+.I-link pabalik sa bagong Kahilingan na Pull sa nakasarang timeline ng Kahilingan na Pull.
 image::images/mentions-03-closed.png[PR closed]
 
-In addition to issue numbers, you can also reference a specific commit by SHA-1. You have to specify a full 40 character SHA-1, but if GitHub sees that in a comment, it will link directly to the commit. Again, you can reference commits in forks or other repositories in the same way you did with issues.
+Bilang karagdagan sa mga numero ng isyu, maaari ka ring magreperensiya ng isang tiyak na commit sa pamamagitan ng SHA-1. Kailangan mong magtukoy ng isang buong 40 karakter na SHA-1, ngunit kung nakikita ito ng GitHub sa komento, ito ay mali-link direkta sa commit. Muli, maaari mong ireperensiya ang mga commit sa mga force o ibang mga repositoryo sa parehong paraan na iyong ginawa sa mga isyu.
 
-==== GitHub Flavored Markdown
+==== Pinalasang Markdown ng GitHub
 
-Linking to other Issues is just the beginning of interesting things you can do with almost any text box on GitHub. In  Issue and Pull Request descriptions, comments, code comments and more, you can use what is called ``GitHub Flavored Markdown''. Markdown is like writing in plain text but which is rendered richly.
+Ang pag-link sa ibang mga Isyu ay simula lamang ng kawili-wiling mga bagay na maaari mong magawa sa halos anumang kahon ng teksto sa GitHub. Sa mga paglalarawan ng Isyu at Kahilingan na Pull, mga komento, mga komento ng code at marami pa, maaari kang gumamit ng tinatawag na ``Pinalasang Markdown ng GitHub''. Ang markdown ay katulad ng pagsusulat sa isang payak na teksto ngunit ibinigay ng mas sagana..
 
-See <<_example_markdown>> for an example of how comments or text can be written and then rendered using Markdown.
+Tingnan ang <<_example_markdown>> para sa isang halimbawa kung paano masusulat ang mga komento at teksto at pagkatapos ay gawin gamit ang Markdown.
 
 [[_example_markdown]]
-.An example of GitHub Flavored Markdown as written and as rendered.
+.Isang halimbawa ng Pinalasang Markdown ng GitHub na nakasulat at nagawa.
 image::images/markdown-01-example.png[Example Markdown]
 
-The GitHub flavor of Markdown adds more things you can do beyond the basic Markdown syntax. These can all be really useful when creating useful Pull Request or Issue comments or descriptions.
+Ang timpla ng Markdown ng GitHub ay nagdadagdag ng mas maraming bagay na maaari mong gawin lampas sa pangunahing Markdown syntax. Ang mga ito ay maaaring magagamit kapag naglilikha ng kapaki-pakinabang na Kahilingan na Pull o mga komento o paglalarawan ng Isyu.
 
-===== Task Lists
+===== Mga Listahan ng Gawain
 
-The first really useful GitHub specific Markdown feature, especially for use in Pull Requests, is the Task List. A task list is a list of checkboxes of things you want to get done. Putting them into an Issue or Pull Request normally indicates things that you want to get done before you consider the item complete.
+Ang una talagang kapaki-pakinabang na tampok ng Markdown na tiyak sa GitHub, lalo na para sa gamit sa mga Kahilingan na Pull, Listahan ng Gawain. Ang listahan ng gawain ay isang listahan ng mga checkbox ng mga bagay na gusto mong tapusin. Paglalagay sa mga ito sa isang Isyu o Kahilingan na Pull ay karaniwang nagpapahiwatig ng mga bagay na gusto mong matapos bago mo isaalang-alang ang mga kompletong aytem.
 
-You can create a task list like this:
+Maaari kang lumikha ng isang listahan ng gawain kagaya nito:
 
 [source,text]
 ----
-- [X] Write the code
-- [ ] Write all the tests
-- [ ] Document the code
+- [X] Isulat ang code
+- [ ] Isulat lahat ang mga pasulit
+- [ ] Idokumento ang code
 ----
 
-If we include this in the description of our Pull Request or Issue, we'll see it rendered like <<_eg_task_lists>>
+Kung ating isasama ang mga ito sa paglalarawan ng ating Kahilingan na Pull o Isyu, makikita natin ito na ginawa tulad ng <<_eg_task_lists>>
 
 [[_eg_task_lists]]
-.Task lists rendered in a Markdown comment.
+.Mga listahan ng gawain na nagawa sa isang komento ng Markdown.
 image::images/markdown-02-tasks.png[Example Task List]
 
-This is often used in Pull Requests to indicate what all you would like to get done on the branch before the Pull Request will be ready to merge. The really cool part is that you can simply click the checkboxes to update the comment -- you don't have to edit the Markdown directly to check tasks off.
+Ito ay kadalasan ginamit sa mga Kahilingan na pull upang ipahiwatig kung ano ang lahat na gusto mong tapusin sa branch bago maging handang i-merge ang Kahilingan na Pull. Ang talagang magandang bahagi ay maaari kang mag-click lamang sa mga checkbox upang ma-update ang komento -- hindi mo na kailangan na baguhin nang direkta ang Markdown upang masuri ang mga gawain.
 
-What's more, GitHub will look for task lists in your Issues and Pull Requests and show them as metadata on the pages that list them out. For example, if you have a Pull Request with tasks and you look at the overview page of all Pull Requests, you can see how far done it is. This helps people break down Pull Requests into subtasks and helps other people track the progress of the branch. You can see an example of this in <<_task_list_progress>>.
+Ano pa, hahanapin ng GitHub ang mga listahan ng gawain sa iyong mga Isyu at Kahilingan na Pull at ipakita ang mga ito bilang metadata sa mga pahina na naglilista sa kanila. Halimbawa, kung mayroon kang Kahilingan na Pull sa mga gawain at titingnan mo ang pahina ng pangkalahatang-ideya ng lahat ng Kahilingan na Pull, maaari mong makita kung gaano kalayo ang ginawa nito. Tinutulungan nito ang mga tao na iwaksi ang Kahilingan na Pull sa mga subtask at tulungan ang ibang tao na subaybayan ang pag-unlad ng branch. Makikita mo ang halimbawa nito sa <<_task_list_progress>>.
 
 [[_task_list_progress]]
-.Task list summary in the Pull Request list.
+.Buod ng listahan ng gawain sa listahan ng Kahilingan na Pull.
 image::images/markdown-03-task-summary.png[Example Task List]
 
-These are incredibly useful when you open a Pull Request early and use it to track your progress through the implementation of the feature.
+Ang mga ito ay hindi kapani-paniwala na kapaki-pakinabang kapag binuksan mo ang isang Kahilingan na Pull nang maaga at gamitin ito upang subaybayan ang iyong pag-unlad sa pamamagitan ng pagpapatupad ng mga tampok.
 
-===== Code Snippets
+===== Mga Code Snippet
 
-You can also add code snippets to comments. This is especially useful if you want to present something that you _could_ try to do before actually implementing it as a commit on your branch. This is also often used to add example code of what is not working or what this Pull Request could implement.
+Maaari ka ring magdagdag ng mga code snippet sa mga komento. Ito ay lalong kapaki-pakinabang kung nais mong ipakita ang isang bagay na _maaari_ mong subukan na gawin bago aktwal na ipatupad ito bilang isang commit sa iyong branch. Ito ay kadalasang ginagamit upang magdagdag ng halimbawa ng code kung ano ang hindi gumagana o kung ano ang maaaring ipatupad ng Kahilingan na Pull.
 
-To add a snippet of code you have to ``fence'' it in backticks.
+Upang magdagdag ng isang snippet sa code, kailangan mong i-``fence'' ito sa mga backtick.
 
 [source,text]
 ----
 ```java
 for(int i=0 ; i < 5 ; i++)
 {
-   System.out.println("i is : " + i);
+   System.out.println("i ay : " + i);
 }
 ```
 ----
 
-If you add a language name like we did there with 'java', GitHub will also try to syntax highlight the snippet. In the case of the above example, it would end up rendering like <<_md_code>>.
+Kung nagdagdag ka ng isang pangalan ng wika tulad ng ginawa natin doon sa 'java', susubukan din ng GitHub na i-highlight ang syntax ng snippet. Sa kaso sa itaas na halimbawa, ito ay matatapos sa paggawa tulad ng <<_md_code>>.
 
 [[_md_code]]
-.Rendered fenced code example.
+.Halimbawa ng naka-render fenced code.
 image::images/markdown-04-fenced-code.png[Rendered fenced code]
 
-===== Quoting
+===== Pag-quote
 
-If you're responding to a small part of a long comment, you can selectively quote out of the other comment by preceding the lines with the `>` character. In fact, this is so common and so useful that there is a keyboard shortcut for it. If you highlight text in a comment that you want to directly reply to and hit the `r` key, it will quote that text in the comment box for you.
+Kung tumutugon ka sa isang maliit na bahagi ng isang mahabang komento, maaari kang pumiling mag-quote ng iba pang komento sa pamamagitan ng nauna sa mga linya kasama ang `>` na karakter. Sa katunayan, ito ay karaniwan at kapaki-pakinabang na may shortcut sa keyboard para dito. Kung iyong i-highlight ang teksto sa isang komento na nais mong direktang tumugon at pindutin ang `r` key, ito ay mag-quote sa teksto na iyon sa kahon ng komento para sa iyo.
 
-The quotes look something like this:
+Ang mga quote ay magiging tulad nito:
 
 [source,text]
 ----
-> Whether 'tis Nobler in the mind to suffer
-> The Slings and Arrows of outrageous Fortune,
+> Kahit na ito'y Nobler sa isip na magdusa
+> Ang mga Sling at Arrow ng mapangahas na Kapalaran,
 
-How big are these slings and in particular, these arrows?
+Gaano kalaki ang mga sling na ito at sa partikular, ang mga arrow na ito?
 ----
 
-Once rendered, the comment will look like <<_md_quote>>.
+Kapag nagawa, ang komento ay magiging tulad ng <<_md_quote>>.
 
 [[_md_quote]]
-.Rendered quoting example.
+.Halimbawa ng nagawang pag-quote.
 image::images/markdown-05-quote.png[Rendered quoting]
 
 ===== Emoji
 
-Finally, you can also use emoji in your comments. This is actually used quite extensively in comments you see on many GitHub Issues and Pull Requests. There is even an emoji helper in GitHub. If you are typing a comment and you start with a `:` character, an autocompleter will help you find what you're looking for.
+Sa wakas, maaari ka ring gumamit ng emoji sa iyong mga komento. Talagang ginagamit ito nang lubos sa mga komento na nakikita mo sa maraming mga isyu ng GitHub at mga Kahilingan na Pull. Mayroon ding isang emoji helper sa GitHub. Kung nagta-type ka ng komento at nagsimula ka ng isang `:` na karakter, tutulungan ka ng autocompleter na makita kung ano ang iyong hinahanap.
 
 [[_md_emoji_auto]]
 .Emoji autocompleter in action.
 image::images/markdown-06-emoji-complete.png[Emoji autocompleter]
 
-Emojis take the form of `:<name>:` anywhere in the comment. For instance, you could write something like this:
+Ang Emojis ay kumukuha sa form ng `:<name>:` saanman sa komento. Halimbawa, maaari kang magsulat ng ilang bagay tulad nito:
 
 [source,text]
 ----
-I :eyes: that :bug: and I :cold_sweat:.
+Ako ay :eyes: sa :bug: at ako'y :cold_sweat:.
 
-:trophy: for :microscope: it.
+:trophy: para :microscope: ito.
 
-:+1: and :sparkles: on this :ship:, it's :fire::poop:!
+:+1: at :sparkles: sa :ship: na ito, ito'y :fire::poop:!
 
 :clap::tada::panda_face:
 ----
 
-When rendered, it would look something like <<_md_emoji>>.
+Kapag nagawa, ito ay magiging tulad ng <<_md_emoji>>.
 
 [[_md_emoji]]
-.Heavy emoji commenting.
+.Mabibigay na pagkokomento na emoji.
 image::images/markdown-07-emoji.png[Emoji]
 
-Not that this is incredibly useful, but it does add an element of fun and emotion to a medium that is otherwise hard to convey emotion in.
 
+Hindi sa ito ay hindi kapani-paniwala kapaki-pakinabang, ngunit ito ay nagdaragdag ng isang elemento ng kasiyahan at damdamin sa isang daluyan na kung hindi man ay mahirap upang ihatid ang damdamin.
 
-[NOTE]
+
+[TANDAAN]
 ====
-There are actually quite a number of web services that make use of emoji characters these days. A great cheat sheet to reference to find emoji that expresses what you want to say can be found at:
+Mayroon talagang maraming bilang ng mga serbisyo ng web na gumagamit sa mga araw na ito ng mga karakter na emoji. Isang magaling na sheet ng panlilinlang na magamit upang mahanap ang emoji na nagpapahayag kung ano ang gusto mong sabihin ay matatagpuan sa:
 
 http://www.emoji-cheat-sheet.com
 ====
 
-===== Images
+===== Mga Larawan
 
-This isn't technically GitHub Flavored Markdown, but it is incredibly useful. In addition to adding Markdown image links to comments, which can be difficult to find and embed URLs for, GitHub allows you to drag and drop images into text areas to embed them.
+Hindi ito Pinalasang Markdown ng GitHub, ngunit ito ay lubhang kapaki-pakinabang. Bilang karagdagan sa pagdaragdag ng mga link ng larawan ng Markdown sa mga komento, na maaaring magin mahirap na mahanap at para ma-embed ang mga URL, ang GitHub ay nagpapahintulot sa iyo na i-drag at ihulog ang mga larawan sa mga text area upang ma-embed ang mga ito.
 
 [[_md_drag]]
-.Drag and drop images to upload them and auto-embed them.
+.I-drag at ihulog ang mga larawan upang ma-upload ito at auto-embed ang mga ito.
 image::images/markdown-08-drag-drop.png[Drag and drop images]
 
-If you look at <<_md_drag>>, you can see a small ``Parsed as Markdown'' hint above the text area. Clicking on that will give you a full cheat sheet of everything you can do with Markdown on GitHub.
+Kung titingnan mo sa <<_md_drag>>, maaari kang makakita ng maliit na hint na ``Naka-parse bilang Markdown'' sa itaas ng text area. Pag-click doon ay magbibigay sa iyo ng buong sheet ng panlilinlang sa lahat na maaari mong gawin sa Markdown ng GitHub.