update zh-hk language Translation

.codeclimate.yml

@@ -0,0 +1,6 @@
+engines:
+  fixme:
+    enabled: true
+ratings:
+  paths: []
+exclude_paths: []

.gitattributes

@@ -2,6 +2,7 @@
 # Set default behavior to automatically normalize line endings.
 ###############################################################################
 * text=auto
+*.xlf eol=crlf
 
 ###############################################################################
 # Set default behavior for command prompt diff.
@@ -17,7 +18,7 @@
 #
 # Merging from the command prompt will add diff markers to the files if there
 # are conflicts (Merging from VS is not affected by the settings below, in VS
-# the diff markers are never inserted). Diff markers may cause the following 
+# the diff markers are never inserted). Diff markers may cause the following
 # file extensions to fail to load in VS. An alternative would be to treat
 # these files as binary and thus will always conflict and require user
 # intervention with every merge. To do so, just uncomment the entries below
@@ -46,9 +47,9 @@
 
 ###############################################################################
 # diff behavior for common document formats
-# 
+#
 # Convert binary document formats to text before diffing them. This feature
-# is only available from the command line. Turn it on by uncommenting the 
+# is only available from the command line. Turn it on by uncommenting the
 # entries below.
 ###############################################################################
 #*.doc   diff=astextplain

.github/CONTRIBUTING.md

@@ -0,0 +1,163 @@
+Contributing to PoGo
+========================
+
+*TL;DR:*
+
+Thanks for contributing!
+-----------
+Issues:
+- Search through existing issues before you create a new one
+- Concise & descriptive issue titles
+- Use the template, it's there for a reason. Your post doesn't fit? -> Contact us via social media.
+
+Pull Requests:
+- Ask before creating PRs with new features or major rewrites
+- Use 4 spaces per indentation level! No tab characters.
+- Keep your local master up-to-date, only work in dedicated branches
+- Always use `git rebase PoGo/master` from feature branch instead of merging.
+
+Long story:  
+We welcome and appreciate contributions from the community.
+There are many ways to become involved with PoGo-UWP:
+including filing issues,
+joining in design conversations,
+writing and improving documentation,
+and contributing to the code.
+Please read the rest of this document to ensure a smooth contribution process.
+
+New to Git?
+-----------
+
+* Make sure you have a [GitHub account](https://github.com/signup/free).
+* Learning Git:
+    * GitHub Help: [Good Resources for Learning Git and GitHub][good-git-resources].
+* [GitHub Flow Guide](https://guides.github.com/introduction/flow/):
+  step-by-step instructions of GitHub flow.
+
+Contributing to Issues
+----------------------
+
+* Check if the issue you are going to file already exists in our [GitHub issues][open-issue].
+* If you can't find your issue already,
+  [open a new issue](https://github.com/ST-Apps/PoGo-UWP/issues/new),
+  making sure to follow the directions as best you can.
+
+Contributing to Code
+--------------------
+### Forks and Pull Requests
+
+GitHub fosters collaboration through the notion of [pull requests][using-prs].
+On GitHub, anyone can [fork][fork-a-repo] an existing repository
+into their own user account, where they can make private changes to their fork.
+To contribute these changes back into the original repository,
+a user simply creates a pull request in order to "request" that the changes be taken "upstream".
+
+Additional references:
+* GitHub's guide on [forking](https://guides.github.com/activities/forking/)
+* GitHub's guide on [Contributing to Open Source](https://guides.github.com/activities/contributing-to-open-source/#pull-request)
+* GitHub's guide on [Understanding the GitHub Flow](https://guides.github.com/introduction/flow/)
+
+
+### Lifecycle of a pull request
+
+#### Before submitting
+
+* To avoid merge conflicts, make sure your branch [is rebased on the `master`](https://github.com/edx/edx-platform/wiki/How-to-Rebase-a-Pull-Request) branch of this repository.
+* Many code changes will require new tests,
+  so make sure you've added a new test if existing tests do not effectively test the code changed.
+* Clean up your commit history.
+  Each commit should be a **single complete** change.
+  This discipline is important when reviewing the changes as well as when using `git bisect` and `git revert`.
+
+
+#### Pull request submission
+
+**Always create a pull request to the `master` branch of this repository**.
+
+* Add a meaningful title of the PR describing what change you want to check in.
+  Don't simply put: "Fixes issue #5".
+  A better example is: "Add Ensure parameter to New-Item cmdlet", with "Fixes #5" in the PR's body.
+
+* When you create a pull request,
+  including a summary of what's included in your changes and
+  if the changes are related to an existing GitHub issue,
+  please reference the issue in pull request description (e.g. ```Closes #11```).
+  See [this][closing-via-message] for more details.
+
+#### Pull Request - Code Review
+
+* After a successful pass,
+  the area maintainers will do a code review,
+  commenting on any changes that might need to be made.
+
+* Additional feedback is always welcome!
+  Even if you are not designated as an area's maintainer,
+  feel free to review others' pull requests anyway.
+  Leave your comments even if everything looks good;
+  a simple "Looks good to me" or "LGTM" will suffice.
+  This way we know someone has already taken a look at it!
+
+* Once the code review is done,
+  and all merge conflicts are resolved,
+  a maintainer should merge your changes.
+
+Common Engineering Practices
+----------------------------
+
+We encourage contributors to follow these common engineering practices:
+
+* Format commit messages following these guidelines:
+
+```
+Summarize change in 50 characters or less
+
+Similar to email, this is the body of the commit message,
+and the above is the subject.
+Always leave a single blank line between the subject and the body
+so that `git log` and `git rebase` work nicely.
+
+The subject of the commit should use the present tense and
+imperative mood, like issuing a command:
+
+> Makes abcd do wxyz
+
+The body should be a useful message explaining
+why the changes were made.
+
+If significant alternative solutions were available,
+explain why they were discarded.
+
+Keep in mind that the person most likely to refer to your commit message
+is you in the future, so be detailed!
+
+As Git commit messages are most frequently viewed in the terminal,
+you should wrap all lines around 72 characters.
+
+Using semantic line feeds (breaks that separate ideas)
+is also appropriate, as is using Markdown syntax.
+```
+
+* These are based on Tim Pope's [guidelines](http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html),
+  Git SCM [submitting patches](https://git.kernel.org/cgit/git/git.git/tree/Documentation/SubmittingPatches),
+  Brandon Rhodes' [semantic linefeeds][],
+  and John Gruber's [Markdown syntax](https://daringfireball.net/projects/markdown/syntax).
+
+* Don't commit code that you didn't write.
+  If you find code that you think is a good fit to add to PoGo-UWP,
+  file an issue and start a discussion before proceeding.
+
+* Create and/or update tests when making code changes.
+
+* Run tests and ensure they are passing before pull request.
+
+* Avoid making big pull requests.
+  Before you invest a large amount of time,
+  file an issue and start a discussion with the community.
+
+[using-prs]: https://help.github.com/articles/using-pull-requests/
+[fork-a-repo]: https://help.github.com/articles/fork-a-repo/
+[closing-via-message]: https://help.github.com/articles/closing-issues-via-commit-messages/
+[good-git-resources]: https://help.github.com/articles/good-resources-for-learning-git-and-github/
+[open-issue]: https://github.com/ST-Apps/PoGo-UWP/issues
+[help-wanted-issue]: https://github.com/ST-Apps/PoGo-UWP/issues?q=is%3Aopen+is%3Aissue+label%3A%220%20-%20Backlog%22
+[semantic linefeeds]: http://rhodesmill.org/brandon/2012/one-sentence-per-line/

.github/ISSUE_TEMPLATE.md

@@ -0,0 +1,32 @@
+<!--
+If it is a bug report:
+- make sure you are able to reproduce it on the latest released version. 
+You can install the latest version from https://github.com/ST-Apps/PoGo-UWP/releases
+- Search the existing issues.
+- Refer to the [Questions & Answers](https://github.com/ST-Apps/PoGo-UWP#questions--answers).
+- Refer to the [known issues](https://github.com/ST-Apps/PoGo-UWP/releases).
+- Fill out the following repro template
+
+If it's not a bug, please remove the template and elaborate the issue in your own words.
+-->
+
+Device info
+------------------
+- Phone type: (e.g. Lumia 950 XL)
+- App version: (e.g. 1.0.25)
+
+Steps to reproduce
+----------------
+
+
+Actual behavior
+-----------------
+
+
+Expected behavior
+---------------
+
+
+Other information
+---------------
+

.github/PULL_REQUEST_TEMPLATE.md

@@ -0,0 +1,17 @@
+Closes issues
+-------------
+- Closes #1
+- Closes #2
+
+Changes
+-------
+- Change 1
+- Change 2
+
+Change details
+--------------
+
+
+Other informations
+------------------
+

.gitignore

@@ -2,7 +2,20 @@
 # This .gitignore file was automatically created by Microsoft(R) Visual Studio.
 ################################################################################
 
+.vs
+project.lock.json
 packages
 bin/
 obj/
 /PokemonGo/RocketAPI/Proto/google/protobuf
+/Google Protobuf
+/PokemonGo-UWP/null
+/PokemonGo-UWP/Utils/BingKey.cs
+/.vs/config/applicationhost.config
+/PokemonGo-UWP/Utils/ApplicationKeys.cs
+/PokemonGo-UWP/AppPackages/
+/PokemonGo-UWP/BundleArtifacts/
+*.suo
+*.user
+*.tss
+/PokemonGo-UWP/BundleArtifacts

.gitmodules

@@ -0,0 +1,6 @@
+[submodule "Pokemon-Go-Rocket-API"]
+	path = Pokemon-Go-Rocket-API
+	url = https://github.com/FeroxRev/Pokemon-Go-Rocket-API.git
+[submodule "Pokemon-GO-App-Assets-and-Images"]
+	path = Pokemon-GO-App-Assets-and-Images
+	url = https://github.com/Superviral/Pokemon-GO-App-Assets-and-Images.git

Google.Protobuf/ByteArray.cs

@@ -0,0 +1,79 @@
+#region Copyright notice and license
+// Protocol Buffers - Google's data interchange format
+// Copyright 2008 Google Inc.  All rights reserved.
+// https://developers.google.com/protocol-buffers/
+//
+// Redistribution and use in source and binary forms, with or without
+// modification, are permitted provided that the following conditions are
+// met:
+//
+//     * Redistributions of source code must retain the above copyright
+// notice, this list of conditions and the following disclaimer.
+//     * Redistributions in binary form must reproduce the above
+// copyright notice, this list of conditions and the following disclaimer
+// in the documentation and/or other materials provided with the
+// distribution.
+//     * Neither the name of Google Inc. nor the names of its
+// contributors may be used to endorse or promote products derived from
+// this software without specific prior written permission.
+//
+// THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
+// "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
+// LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+// A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
+// OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+// SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
+// LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
+// DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
+// THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+// (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+// OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+#endregion
+
+using System;
+
+namespace Google.Protobuf
+{
+    /// <summary>
+    /// Provides a utility routine to copy small arrays much more quickly than Buffer.BlockCopy
+    /// </summary>
+    internal static class ByteArray
+    {
+        /// <summary>
+        /// The threshold above which you should use Buffer.BlockCopy rather than ByteArray.Copy
+        /// </summary>
+        private const int CopyThreshold = 12;
+
+        /// <summary>
+        /// Determines which copy routine to use based on the number of bytes to be copied.
+        /// </summary>
+        internal static void Copy(byte[] src, int srcOffset, byte[] dst, int dstOffset, int count)
+        {
+            if (count > CopyThreshold)
+            {
+                Buffer.BlockCopy(src, srcOffset, dst, dstOffset, count);
+            }
+            else
+            {
+                int stop = srcOffset + count;
+                for (int i = srcOffset; i < stop; i++)
+                {
+                    dst[dstOffset++] = src[i];
+                }
+            }
+        }
+
+        /// <summary>
+        /// Reverses the order of bytes in the array
+        /// </summary>
+        internal static void Reverse(byte[] bytes)
+        {
+            for (int first = 0, last = bytes.Length - 1; first < last; first++, last--)
+            {
+                byte temp = bytes[first];
+                bytes[first] = bytes[last];
+                bytes[last] = temp;
+            }
+        }
+    }
+}