1 files changed, 435 insertions, 0 deletions
diff --git a/docs/_locale/ja_JP/LC_MESSAGES/development.po b/docs/_locale/ja_JP/LC_MESSAGES/development.po
new file mode 100644
index 0000000..1a40fdb
--- /dev/null
+++ b/docs/_locale/ja_JP/LC_MESSAGES/development.po
@@ -0,0 +1,435 @@
+# SOME DESCRIPTIVE TITLE.
+# Copyright (C) 2009-2020, Marcel Hellkamp
+# This file is distributed under the same license as the Bottle package.
+# 
+# Translators:
+msgid ""
+msgstr ""
+"Project-Id-Version: bottle\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2020-12-31 18:35+0100\n"
+"PO-Revision-Date: 2020-12-31 17:35+0000\n"
+"Last-Translator: defnull <marc@gsites.de>\n"
+"Language-Team: Japanese (Japan) (http://www.transifex.com/bottle/bottle/language/ja_JP/)\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Language: ja_JP\n"
+"Plural-Forms: nplurals=1; plural=0;\n"
+
+#: ../../development.rst:2
+msgid "Developer Notes"
+msgstr ""
+
+#: ../../development.rst:4
+msgid ""
+"This document is intended for developers and package maintainers interested "
+"in the bottle development and release workflow. If you want to contribute, "
+"you are just right!"
+msgstr ""
+
+#: ../../development.rst:8
+msgid "Get involved"
+msgstr ""
+
+#: ../../development.rst:10
+msgid ""
+"There are several ways to join the community and stay up to date. Here are "
+"some of them:"
+msgstr ""
+
+#: ../../development.rst:12
+msgid ""
+"**Mailing list**: Join our mailing list by sending an email to "
+"`bottlepy+subscribe@googlegroups.com "
+"<mailto:bottlepy+subscribe@googlegroups.com>`_ (no google account required)."
+msgstr ""
+
+#: ../../development.rst:13
+msgid ""
+"**Twitter**: `Follow us on Twitter <https://twitter.com/bottlepy>`_ or "
+"search for the `#bottlepy <https://twitter.com/#!/search/%23bottlepy>`_ tag."
+msgstr ""
+
+#: ../../development.rst:14
+msgid ""
+"**IRC**: Join `#bottlepy on irc.freenode.net "
+"<irc://irc.freenode.net/bottlepy>`_ or use the `web chat interface "
+"<http://webchat.freenode.net/?channels=bottlepy>`_."
+msgstr ""
+
+#: ../../development.rst:15
+msgid ""
+"**Google plus**: We sometimes `blog about Bottle, releases and technical "
+"stuff "
+"<https://plus.google.com/b/104025895326575643538/104025895326575643538/posts>`_"
+" on our Google+ page."
+msgstr ""
+
+#: ../../development.rst:19
+msgid "Get the Sources"
+msgstr ""
+
+#: ../../development.rst:21
+msgid ""
+"The bottle `development repository <https://github.com/bottlepy/bottle>`_ "
+"and the `issue tracker <https://github.com/bottlepy/bottle/issues>`_ are "
+"both hosted at `github <https://github.com/bottlepy/bottle>`_. If you plan "
+"to contribute, it is a good idea to create an account there and fork the "
+"main repository. This way your changes and ideas are visible to other "
+"developers and can be discussed openly. Even without an account, you can "
+"clone the repository or just download the latest development version as a "
+"source archive."
+msgstr ""
+
+#: ../../development.rst:23
+msgid "**git:** ``git clone git://github.com/bottlepy/bottle.git``"
+msgstr ""
+
+#: ../../development.rst:24
+msgid "**git/https:** ``git clone https://github.com/bottlepy/bottle.git``"
+msgstr ""
+
+#: ../../development.rst:25
+msgid ""
+"**Download:** Development branch as `tar archive "
+"<http://github.com/bottlepy/bottle/tarball/master>`_ or `zip file "
+"<http://github.com/bottlepy/bottle/zipball/master>`_."
+msgstr ""
+
+#: ../../development.rst:26
+msgid ""
+"**Translations:** `transifex.com/projects/p/bottle "
+"<https://www.transifex.com/projects/p/bottle/>`_"
+msgstr ""
+
+#: ../../development.rst:30
+msgid "Releases and Updates"
+msgstr ""
+
+#: ../../development.rst:32
+msgid ""
+"Bottle is released at irregular intervals and distributed through `PyPI "
+"<http://pypi.python.org/pypi/bottle>`_. Release candidates and bugfix-"
+"revisions of outdated releases are only available from the git repository "
+"mentioned above. Some Linux distributions may offer packages for outdated "
+"releases, though."
+msgstr ""
+
+#: ../../development.rst:34
+msgid ""
+"The Bottle version number splits into three parts "
+"(**major.minor.revision**). These are *not* used to promote new features but"
+" to indicate important bug-fixes and/or API changes. Critical bugs are fixed"
+" in at least the two latest minor releases and announced in all available "
+"channels (mailinglist, twitter, github). Non-critical bugs or features are "
+"not guaranteed to be backported. This may change in the future, through."
+msgstr ""
+
+#: ../../development.rst:37
+msgid "Major Release (x.0)"
+msgstr ""
+
+#: ../../development.rst:37
+msgid ""
+"The major release number is increased on important milestones or updates "
+"that completely break backward compatibility. You probably have to work over"
+" your entire application to use a new release. These releases are very rare,"
+" through."
+msgstr ""
+
+#: ../../development.rst:40
+msgid "Minor Release (x.y)"
+msgstr ""
+
+#: ../../development.rst:40
+msgid ""
+"The minor release number is increased on updates that change the API or "
+"behaviour in some way. You might get some depreciation warnings any may have"
+" to tweak some configuration settings to restore the old behaviour, but in "
+"most cases these changes are designed to be backward compatible for at least"
+" one minor release. You should update to stay up do date, but don't have to."
+" An exception is 0.8, which *will* break backward compatibility hard. (This "
+"is why 0.7 was skipped). Sorry about that."
+msgstr ""
+
+#: ../../development.rst:43
+msgid "Revision (x.y.z)"
+msgstr ""
+
+#: ../../development.rst:43
+msgid ""
+"The revision number is increased on bug-fixes and other patches that do not "
+"change the API or behaviour. You can safely update without editing your "
+"application code. In fact, you really should as soon as possible, because "
+"important security fixes are released this way."
+msgstr ""
+
+#: ../../development.rst:47
+msgid "Pre-Release Versions"
+msgstr ""
+
+#: ../../development.rst:46
+msgid ""
+"Release candidates are marked by an ``rc`` in their revision number. These "
+"are API stable most of the time and open for testing, but not officially "
+"released yet. You should not use these for production."
+msgstr ""
+
+#: ../../development.rst:50
+msgid "Repository Structure"
+msgstr ""
+
+#: ../../development.rst:52
+msgid "The source repository is structured as follows:"
+msgstr ""
+
+#: ../../development.rst:55
+msgid "``master`` branch"
+msgstr ""
+
+#: ../../development.rst:55
+msgid ""
+"This is the integration, testing and development branch. All changes that "
+"are planned to be part of the next release are merged and tested here."
+msgstr ""
+
+#: ../../development.rst:58
+msgid "``release-x.y`` branches"
+msgstr ""
+
+#: ../../development.rst:58
+msgid ""
+"As soon as the master branch is (almost) ready for a new release, it is "
+"branched into a new release branch. This \"release candidate\" is feature-"
+"frozen but may receive bug-fixes and last-minute changes until it is "
+"considered production ready and officially released. From that point on it "
+"is called a \"support branch\" and still receives bug-fixes, but only "
+"important ones. The revision number is increased on each push to these "
+"branches, so you can keep up with important changes."
+msgstr ""
+
+#: ../../development.rst:62
+msgid "Feature branches"
+msgstr ""
+
+#: ../../development.rst:61
+msgid ""
+"All other branches are feature branches. These are based on the master "
+"branch and only live as long as they are still active and not merged back "
+"into ``master``."
+msgstr ""
+
+#: ../../development.rst:65
+msgid "What does this mean for a developer?"
+msgstr ""
+
+#: ../../development.rst:66
+msgid ""
+"If you want to add a feature, create a new branch from ``master``. If you "
+"want to fix a bug, branch ``release-x.y`` for each affected release. Please "
+"use a separate branch for each feature or bug to make integration as easy as"
+" possible. Thats all. There are git workflow examples at the bottom of this "
+"page."
+msgstr ""
+
+#: ../../development.rst:68
+msgid ""
+"Oh, and never ever change the release number. We'll do that on integration. "
+"You never know in which order we pull pending requests anyway :)"
+msgstr ""
+
+#: ../../development.rst:72
+msgid "What does this mean for a maintainer ?"
+msgstr ""
+
+#: ../../development.rst:73
+msgid ""
+"Watch the tags (and the mailing list) for bug-fixes and new releases. If you"
+" want to fetch a specific release from the git repository, trust the tags, "
+"not the branches. A branch may contain changes that are not released yet, "
+"but a tag marks the exact commit which changed the version number."
+msgstr ""
+
+#: ../../development.rst:77
+msgid "Submitting Patches"
+msgstr ""
+
+#: ../../development.rst:79
+msgid ""
+"The best way to get your changes integrated into the main development branch"
+" is to fork the main repository at github, create a new feature-branch, "
+"apply your changes and send a pull-request. Further down this page is a "
+"small collection of git workflow examples that may guide you. Submitting "
+"git-compatible patches to the mailing list is fine too. In any case, please "
+"follow some basic rules:"
+msgstr ""
+
+#: ../../development.rst:81
+msgid ""
+"**Documentation:** Tell us what your patch does. Comment your code. If you "
+"introduced a new feature, add to the documentation so others can learn about"
+" it."
+msgstr ""
+
+#: ../../development.rst:82
+msgid ""
+"**Test:** Write tests to prove that your code works as expected and does not"
+" break anything. If you fixed a bug, write at least one test-case that "
+"triggers the bug. Make sure that all tests pass before you submit a patch."
+msgstr ""
+
+#: ../../development.rst:83
+msgid ""
+"**One patch at a time:** Only fix one bug or add one feature at a time. "
+"Design your patches so that they can be applyed as a whole. Keep your "
+"patches clean, small and focused."
+msgstr ""
+
+#: ../../development.rst:84
+msgid ""
+"**Sync with upstream:** If the ``upstream/master`` branch changed while you "
+"were working on your patch, rebase or pull to make sure that your patch "
+"still applies without conflicts."
+msgstr ""
+
+#: ../../development.rst:88
+msgid "Building the Documentation"
+msgstr ""
+
+#: ../../development.rst:90
+msgid ""
+"You need a recent version of Sphinx to build the documentation. The "
+"recommended way is to install :command:`virtualenv` using your distribution "
+"package repository and install sphinx manually to get an up-to-date version."
+msgstr ""
+
+#: ../../development.rst:121
+msgid "GIT Workflow Examples"
+msgstr ""
+
+#: ../../development.rst:123
+msgid ""
+"The following examples assume that you have an (free) `github account "
+"<https://github.com>`_. This is not mandatory, but makes things a lot "
+"easier."
+msgstr ""
+
+#: ../../development.rst:125
+msgid ""
+"First of all you need to create a fork (a personal clone) of the official "
+"repository. To do this, you simply click the \"fork\" button on the `bottle "
+"project page <https://github.com/bottlepy/bottle>`_. When the fork is done, "
+"you will be presented with a short introduction to your new repository."
+msgstr ""
+
+#: ../../development.rst:127
+msgid ""
+"The fork you just created is hosted at github and read-able by everyone, but"
+" write-able only by you. Now you need to clone the fork locally to actually "
+"make changes to it. Make sure you use the private (read-write) URL and *not*"
+" the public (read-only) one::"
+msgstr ""
+
+#: ../../development.rst:131
+msgid ""
+"Once the clone is complete your repository will have a remote named "
+"\"origin\" that points to your fork on github. Don’t let the name confuse "
+"you, this does not point to the original bottle repository, but to your own "
+"fork. To keep track of the official repository, add another remote named "
+"\"upstream\"::"
+msgstr ""
+
+#: ../../development.rst:137
+msgid ""
+"Note that \"upstream\" is a public clone URL, which is read-only. You cannot"
+" push changes directly to it. Instead, we will pull from your public "
+"repository. This is described later."
+msgstr ""
+
+#: ../../development.rst:140
+msgid "Submit a Feature"
+msgstr ""
+
+#: ../../development.rst:141
+msgid ""
+"New features are developed in separate feature-branches to make integration "
+"easy. Because they are going to be integrated into the ``master`` branch, "
+"they must be based on ``upstream/master``. To create a new feature-branch, "
+"type the following::"
+msgstr ""
+
+#: ../../development.rst:145
+msgid ""
+"Now implement your feature, write tests, update the documentation, make sure"
+" that all tests pass and commit your changes::"
+msgstr ""
+
+#: ../../development.rst:149
+msgid ""
+"If the ``upstream/master`` branch changed in the meantime, there may be "
+"conflicts with your changes. To solve these, 'rebase' your feature-branch "
+"onto the top of the updated ``upstream/master`` branch::"
+msgstr ""
+
+#: ../../development.rst:154
+msgid ""
+"This is equivalent to undoing all your changes, updating your branch to the "
+"latest version and reapplying all your patches again. If you released your "
+"branch already (see next step), this is not an option because it rewrites "
+"your history. You can do a normal pull instead. Resolve any conflicts, run "
+"the tests again and commit."
+msgstr ""
+
+#: ../../development.rst:156
+msgid ""
+"Now you are almost ready to send a pull request. But first you need to make "
+"your feature-branch public by pushing it to your github fork::"
+msgstr ""
+
+#: ../../development.rst:160
+msgid ""
+"After you’ve pushed your commit(s) you need to inform us about the new "
+"feature. One way is to send a pull-request using github. Another way would "
+"be to start a thread in the mailing-list, which is recommended. It allows "
+"other developers to see and discuss your patches and you get some feedback "
+"for free :)"
+msgstr ""
+
+#: ../../development.rst:162
+msgid ""
+"If we accept your patch, we will integrate it into the official development "
+"branch and make it part of the next release."
+msgstr ""
+
+#: ../../development.rst:165
+msgid "Fix a Bug"
+msgstr ""
+
+#: ../../development.rst:166
+msgid ""
+"The workflow for bug-fixes is very similar to the one for features, but "
+"there are some differences:"
+msgstr ""
+
+#: ../../development.rst:168
+msgid ""
+"Branch off of the affected release branches instead of just the development "
+"branch."
+msgstr ""
+
+#: ../../development.rst:169
+msgid "Write at least one test-case that triggers the bug."
+msgstr ""
+
+#: ../../development.rst:170
+msgid ""
+"Do this for each affected branch including ``upstream/master`` if it is "
+"affected. ``git cherry-pick`` may help you reducing repetitive work."
+msgstr ""
+
+#: ../../development.rst:171
+msgid ""
+"Name your branch after the release it is based on to avoid confusion. "
+"Examples: ``my_bugfix-x.y`` or ``my_bugfix-dev``."
+msgstr ""