{"title":"Pisanie pierwszej aplikacji Django, część 2.","version":"6.0","locale":"pl","docname":"intro/tutorial02","url":"/pl/6.0/intro/tutorial02/","canonical":"https://djangodocs.dev/pl/6.0/intro/tutorial02/","summary":"Ten tutorial zaczyna się tam, gdzie skończył się Tutorial 1 . Będziemy uruchamiać bazę danych, stworzymy twój pierwszy model i przejdziemy krótki wstęp do…","html":"

Pisanie pierwszej aplikacji Django, część 2.Link to this heading#

\n

Ten tutorial zaczyna się tam, gdzie skończył się Tutorial 1. Będziemy uruchamiać bazę danych, stworzymy twój pierwszy model i przejdziemy krótki wstęp do automatycznie generowanego panelu administracyjnego Django.

\n\n
\n

Konfiguracja bazy danychLink to this heading#

\n

Otwórz teraz mysite/settings.py. To normalny moduł Pythona ze zmiennymi poziomu modułu reprezentującymi ustawienia Django.

\n

By default, the DATABASES configuration uses SQLite. If you’re new\nto databases, or you’re just interested in trying Django, this is the easiest\nchoice. SQLite is included in Python, so you won’t need to install anything\nelse to support your database. When starting your first real project, however,\nyou may want to use a more scalable database like PostgreSQL, to avoid\ndatabase-switching headaches down the road.

\n

If you wish to use another database, see details to customize and get\nyour database running.

\n

W trakcie edycji mysite/settings.py, ustaw TIME_ZONE na swoją strefę czasową.

\n

Zwróć również uwagę na ustawienie INSTALLED_APPS na początku pliku. Trzyma ono nazwy wszystkich aplikacji Django, które są aktywowane w tej instancji Django. Aplikacje mogę być używane w wielu projektach i możesz je pakować i udostępniać innym do użytku w ich projektach.

\n

Domyślnie INSTALLED_APPS zawiera następujące aplikacje, które są w pakiecie z Django:

\n\n

Aplikacje te są włączone domyślnie jako udogodnienie dla powszechnych spraw.

\n

Niektóre z tych aplikacji używają przynajmniej jednej tabeli w bazie danych, więc musimy stworzyć tabele w bazie danych zanim będziemy mogli je użyć. Aby to zrobić, uruchom następującą komendę:

\n

Linux / macOS

Shell
$ python manage.py migrate\n
\n

Windows

Windows
...\\> py manage.py migrate\n
\n

Komenda migrate spogląda w ustawienie INSTALLED_APPS i tworzy potrzebne tabele bazy danych w nawiązaniu do ustawień bazy danych w twoim pliku mysite/settings.py i do migracji bazy danych zawartych w aplikacji (powiemy o tym później). Zobaczysz wiadomość o każdej migracji, która zostanie zastosowana. Jeśli jesteś zainsteresowany, uruchom klienta linii poleceń twojej bazy danych i wpisz \\dt (PostgreSQL), SHOW TABLES; (MariaDB, MySQL), .tables (SQLite) lub SELECT TABLE_NAME FROM USER_TABLES; (Oracle), aby wyświetlić tabele, które stworzyło Django.

\n\n
\n
\n

Tworzenie modeliLink to this heading#

\n

Teraz zdefiniujemy twoje modele – w istocie layout twojej bazy danych z dodatkowymi meta-danymi.

\n\n

W naszej aplikacji ankietowej, stworzymy dwa modele: Question and Choice. Question ma pytanie i datę publikacji. Choice ma dwa pola: treść wyboru i podsumowanie głosów. Każdy Choice jest związane z Question.

\n

Te koncepty są reprezentowane przez klasy Pythona. Zmień plik polls/models.py, aby wyglądał tak:

\n
polls/models.py
\n
Python
from django.db import models\n\n\nclass Question(models.Model):\n    question_text = models.CharField(max_length=200)\n    pub_date = models.DateTimeField("date published")\n\n\nclass Choice(models.Model):\n    question = models.ForeignKey(Question, on_delete=models.CASCADE)\n    choice_text = models.CharField(max_length=200)\n    votes = models.IntegerField(default=0)\n
\n

Każdy model jest reprezentowany przez klasę, która dziedziczy po django.db.models.Model. Każdy model ma kilka zmiennych klasowych, z których każda reprezentuje pole bazy danych w modelu.

\n

Każde pole jest reprezentowane przez instancję klasy Field – na przykład CharField dla pól znakowych i DateTimeField dla dat i czasu. Mówi to Django, jakie dane przechowuje każde pole.

\n

Nazwa każdej instancji Field (np. question_text lub pub_date) jest nazwą pola, w formacie przyjaznym maszynom. Użyjesz tej wartości w kodzie Pythona i twoja baza danych użyje jej jako nazwy kolumny.

\n

Można użyć opcjonalnego pierwszego argumentu pozycyjnego w Field, aby wyznaczyć nazwę w postaci czytelnej dla człowieka. Jest ona używana w kilku introspekcyjnych częściach Django i może służyć jako dokumentacja. Jeśli nie podamy tego argumentu, Django będzie używać nazwy maszynowej. W tym przykładzie mamy zdefiniowaną nazwę w postaci czytelnej dla człowieka tylko dla Question.pub_date. Dla wszystkich innych pól w tym modelu, nazwy maszynowe będą wystarczające jako nazwy pól w formie czytelnej dla człowieka.

\n

Niektóre klasy Field mają wymagane argumenty. Na przykład CharField wymaga podania atrybutu max_length. Jest on używany nie tylko w schemacie bazy danych, ale również w walidacji, jak wkrótce zobaczymy.

\n

Field może mieć też kilka opcjonalnych argumentów; w tym przypadku ustawiliśmy wartość atrybutu default pola votes na 0.

\n

I wreszcie, zwróć uwagę na zdefiniowaną relację przy użyciu ForeignKey. Mówi to Django, że każdy Choice jest związany z pojedynczym Question. Django wspiera wszystkie powszechne relacje w bazach danych: wiele-do-jednego, wiele-do-wielu i jeden-do-jednego.

\n
\n
\n

Włączanie modeliLink to this heading#

\n

Taki mały kawałek kodu modelu daje Django wiele informacji. Na ich podstawie, Django jest w stanie:

\n\n

Ale najpierw musimy powiedziesz naszemu projektowi, że aplikacja polls jest zainstalowana.

\n\n

Aby zawrzeć aplikację w naszym projekcie, musimy dodać odniesienie do jej klasy konfiguracyjnej w ustawieniu INSTALLED_APPS. Klasa PollsConfig jest w pliku polls/apps.py, więc jej kropkowana ścieżka to 'polls.apps.PollsConfig'. Zmień plik mysite/settings.py i dodaj tę kropkowaną ścieżkę do ustawienia INSTALLED_APPS. Będzie to wyglądało tak:

\n
mysite/settings.py
\n
Python
INSTALLED_APPS = [\n    "polls.apps.PollsConfig",\n    "django.contrib.admin",\n    "django.contrib.auth",\n    "django.contrib.contenttypes",\n    "django.contrib.sessions",\n    "django.contrib.messages",\n    "django.contrib.staticfiles",\n]\n
\n

Teraz Django wie, że ma zawierać aplikację polls. Uruchommy następne polecenie:

\n

Linux / macOS

Shell
$ python manage.py makemigrations polls\n
\n

Windows

Windows
...\\> py manage.py makemigrations polls\n
\n

Powinieneś zobaczyć coś podobnego do tego:

\n
Text
Migrations for 'polls':\n  polls/migrations/0001_initial.py\n    + Create model Question\n    + Create model Choice\n
\n

Uruchamiając makemigrations, mówisz Django, że dokonałeś jakichś zmian w swoich modelach (w tym przypadku stworzyłeś nowe) i chcesz, aby te zmiany były przechowane jako migracja.

\n

Migracje, to sposób w jaki Django przechowuje zmiany twoich modeli (i przez to zmiany schematu bazy danych) – są plikami na dysku. Możesz przeczytać migrację dla twojego nowego modelu, jeśli masz ochotę; to plik polls/migrations/0001_initial.py. Nie przejmuj się, nie musisz ich czytać za każdym razem, kiedy Django je tworzy, ale zostały one zaprojektowane, aby były modyfikowalne przez dewelopera, na wypadek, gdybyś chciał ręcznie poprawić to, jak Django zmienia rzeczy.

\n

Jest komenda, która uruchomi dla ciebie migracje i będzie zarządzać automatycznie schematem bazy danych – nazywa się migrate i zaraz do niej dojdziemy – ale najpierw zobaczmy, jaki kod SQL ta migracja uruchomiła. Komenda sqlmigrate bierze jako argument nazwy migracji i zwraca ich SQL:

\n

Linux / macOS

Shell
$ python manage.py sqlmigrate polls 0001\n
\n

Windows

Windows
...\\> py manage.py sqlmigrate polls 0001\n
\n

Powinieneś zobaczyć coś podobnego do tego (sformatowaliśmy dla czytelności):

\n
SQL
BEGIN;\n--\n-- Create model Question\n--\nCREATE TABLE "polls_question" (\n    "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,\n    "question_text" varchar(200) NOT NULL,\n    "pub_date" timestamp with time zone NOT NULL\n);\n--\n-- Create model Choice\n--\nCREATE TABLE "polls_choice" (\n    "id" bigint NOT NULL PRIMARY KEY GENERATED BY DEFAULT AS IDENTITY,\n    "choice_text" varchar(200) NOT NULL,\n    "votes" integer NOT NULL,\n    "question_id" bigint NOT NULL\n);\nALTER TABLE "polls_choice"\n  ADD CONSTRAINT "polls_choice_question_id_c5b4b260_fk_polls_question_id"\n    FOREIGN KEY ("question_id")\n    REFERENCES "polls_question" ("id")\n    DEFERRABLE INITIALLY DEFERRED;\nCREATE INDEX "polls_choice_question_id_c5b4b260" ON "polls_choice" ("question_id");\n\nCOMMIT;\n
\n

Zwróć uwagę na następującą rzecz:

\n\n

Jeśli jesteś zainteresowany, możesz też uruchomić python manage.py check; sprawdzi to jakiekolwiek problemy w twoim projekcie bez robienia migracji lub dotykania bazy danych.

\n

Teraz uruchom ponowinie migrate, aby stworzyć te tabele modeli w twojej bazie danych:

\n

Linux / macOS

Shell
$ python manage.py migrate\nOperations to perform:\n  Apply all migrations: admin, auth, contenttypes, polls, sessions\nRunning migrations:\n  Applying polls.0001_initial... OK\n
\n

Windows

Windows
...\\> py manage.py migrate\nOperations to perform:\n  Apply all migrations: admin, auth, contenttypes, polls, sessions\nRunning migrations:\n  Applying polls.0001_initial... OK\n
\n

Komenda migrate bierze wszystkie migracje, które jeszcze nie zostały zastosowane (Django śledzi, które są już zastosowane używając specjalnej tabeli w twojej bazie danych nazwanej django_migrations) i uruchamia je na twojej bazie danych – to znaczy synchronizuje zmiany, które zrobiłeś w modelach ze schematem danych w bazie danych.

\n

Migracje są potężnym narzędziem, pozwalając ci zmieniać twoje modele w czasie, gdy rozwijasz swój projekt, bez konieczności usuwania bazy danych lub tabel i tworzenia nowych – specjalizuje się w upgrade’owaniu twojej bazy danych na żywo, bez tracenia danych. Omówimy je bardziej dogłębnie w późniejszej części tutorialu, lecz teraz zapamiętaj trzy kroki do tworzenia zmian w modelach:

\n\n

Powodem, dla którego komendy do tworzenia i stosowania migracji są rozdzielne, jest to, że będziesz commitował migracje do swojego systemu kontroli wersji i zawrzesz je w swojej aplikacji; one nie tylko ułatwiają dewelopment, ale też są użyteczne dla innych deweloperów i w produkcji.

\n

Przeczytaj dokumentację django-admin, aby uzyskać pełną informację, co może robić narzędzie manage.py.

\n
\n
\n

Zabawa z APILink to this heading#

\n

Teraz wskoczmy do interaktywnego shella Pythona i pobawmy się z otwartym API, które daje Django. Aby wywołać Pythonowego shella, użyj tej komendy:

\n

Linux / macOS

Shell
$ python manage.py shell\n
\n

Windows

Windows
...\\> py manage.py shell\n
\n

We’re using this instead of simply typing „python”, because manage.py\nsets the DJANGO_SETTINGS_MODULE environment variable, which gives\nDjango the Python import path to your mysite/settings.py file.\nBy default, the shell command automatically imports the models from\nyour INSTALLED_APPS.

\n

Kiedy już jesteś w shellu, zbadaj API bazy danych:

\n
Python console
# No questions are in the system yet.\n>>> Question.objects.all()\n<QuerySet []>\n\n# Create a new Question.\n# Support for time zones is enabled in the default settings file, so\n# Django expects a datetime with tzinfo for pub_date. Use timezone.now()\n# instead of datetime.datetime.now() and it will do the right thing.\n>>> from django.utils import timezone\n>>> q = Question(question_text="What's new?", pub_date=timezone.now())\n\n# Save the object into the database. You have to call save() explicitly.\n>>> q.save()\n\n# Now it has an ID.\n>>> q.id\n1\n\n# Access model field values via Python attributes.\n>>> q.question_text\n"What's new?"\n>>> q.pub_date\ndatetime.datetime(2012, 2, 26, 13, 0, 0, 775217, tzinfo=datetime.UTC)\n\n# Change values by changing the attributes, then calling save().\n>>> q.question_text = "What's up?"\n>>> q.save()\n\n# objects.all() displays all the questions in the database.\n>>> Question.objects.all()\n<QuerySet [<Question: Question object (1)>]>\n
\n

Ale zaraz. <Question: Question object (1)> nie jest pomocną reprezentacją tego obiektu. Poprawmy to edytując model Question (w pliku polls/models.py) i dodając metodę __str__() zarówno do Question jak i Choice:

\n
polls/models.py
\n
Python
from django.db import models\n\n\nclass Question(models.Model):\n    # ...\n    def __str__(self):\n        return self.question_text\n\n\nclass Choice(models.Model):\n    # ...\n    def __str__(self):\n        return self.choice_text\n
\n

Dodanie metod __str__() do twoich modeli jest ważne, nie tylko dla twojej własnej wygody, gdy używasz interaktywnego prompta, ale także dlatego, że reprezentacje obiektów są używane w automatycznie generowanym panelu administracyjnym Django.

\n

Dodajmy też własną metodę do tego modelu:

\n
polls/models.py
\n
Python
import datetime\n\nfrom django.db import models\nfrom django.utils import timezone\n\n\nclass Question(models.Model):\n    # ...\n    def was_published_recently(self):\n        return self.pub_date >= timezone.now() - datetime.timedelta(days=1)\n
\n

Zwróć uwagę na import datetime i from django.utils import timezone, odwołujące się kolejno do standardowego modułu Pythona datetime i narzędzi Django związanych ze strefami czasowymi w django.utils.timezone. Jeśli nie jesteś zaznajomiony z obsługą stref czasowych w Pythonie, możesz dowiedzieć się więcej w dokumentacji wsparcia stref czasowych.

\n

Save these changes and start a new Python interactive shell. (If a\nthree-chevron prompt (>>>) indicates you are still in the shell, you need to\nexit first using exit()). Run python manage.py shell again to reload\nthe models.

\n
Python console
# Make sure our __str__() addition worked.\n>>> Question.objects.all()\n<QuerySet [<Question: What's up?>]>\n\n# Django provides a rich database lookup API that's entirely driven by\n# keyword arguments.\n>>> Question.objects.filter(id=1)\n<QuerySet [<Question: What's up?>]>\n>>> Question.objects.filter(question_text__startswith="What")\n<QuerySet [<Question: What's up?>]>\n\n# Get the question that was published this year.\n>>> from django.utils import timezone\n>>> current_year = timezone.now().year\n>>> Question.objects.get(pub_date__year=current_year)\n<Question: What's up?>\n\n# Request an ID that doesn't exist, this will raise an exception.\n>>> Question.objects.get(id=2)\nTraceback (most recent call last):\n    ...\nDoesNotExist: Question matching query does not exist.\n\n# Lookup by a primary key is the most common case, so Django provides a\n# shortcut for primary-key exact lookups.\n# The following is identical to Question.objects.get(id=1).\n>>> Question.objects.get(pk=1)\n<Question: What's up?>\n\n# Make sure our custom method worked.\n>>> q = Question.objects.get(pk=1)\n>>> q.was_published_recently()\nTrue\n\n# Give the Question a couple of Choices. The create call constructs a new\n# Choice object, does the INSERT statement, adds the choice to the set\n# of available choices and returns the new Choice object. Django creates\n# a set (defined as "choice_set") to hold the "other side" of a ForeignKey\n# relation (e.g. a question's choice) which can be accessed via the API.\n>>> q = Question.objects.get(pk=1)\n\n# Display any choices from the related object set -- none so far.\n>>> q.choice_set.all()\n<QuerySet []>\n\n# Create three choices.\n>>> q.choice_set.create(choice_text="Not much", votes=0)\n<Choice: Not much>\n>>> q.choice_set.create(choice_text="The sky", votes=0)\n<Choice: The sky>\n>>> c = q.choice_set.create(choice_text="Just hacking again", votes=0)\n\n# Choice objects have API access to their related Question objects.\n>>> c.question\n<Question: What's up?>\n\n# And vice versa: Question objects get access to Choice objects.\n>>> q.choice_set.all()\n<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>\n>>> q.choice_set.count()\n3\n\n# The API automatically follows relationships as far as you need.\n# Use double underscores to separate relationships.\n# This works as many levels deep as you want; there's no limit.\n# Find all Choices for any question whose pub_date is in this year\n# (reusing the 'current_year' variable we created above).\n>>> Choice.objects.filter(question__pub_date__year=current_year)\n<QuerySet [<Choice: Not much>, <Choice: The sky>, <Choice: Just hacking again>]>\n\n# Let's delete one of the choices. Use delete() for that.\n>>> c = q.choice_set.filter(choice_text__startswith="Just hacking")\n>>> c.delete()\n
\n

Po więcej informacji na temat relacji między modelami, zobacz Dostęp do powiązanych obiektów.

\n
\n
\n

Wprowadzenie do panelu administracyjnego DjangoLink to this heading#

\n\n
\n

Tworzenie konta administratoraLink to this heading#

\n

Najpierw musimy stworzyć użytkownika, który może logować się do panelu administracyjnego. Uruchom następującą komendę:

\n

Linux / macOS

Shell
$ python manage.py createsuperuser\n
\n

Windows

Windows
...\\> py manage.py createsuperuser\n
\n

Wprowadź swoją pożądaną nazwę użytkownika i naciśnij enter.

\n
Text
Username: admin\n
\n

Zostaniesz poproszony o swój adres e-mail:

\n
Text
Email address: admin@example.com\n
\n

Ostatnim krokiem jest wprowadzenie hasła. Zostaniesz poproszony o wprowadzenie swojego hasła dwa razy, drugi raz na potwierdzenie pierwszego.

\n
Text
Password: **********\nPassword (again): *********\nSuperuser created successfully.\n
\n
\n
\n

Uruchom serwer deweloperskiLink to this heading#

\n

Panel administracyjny Django jest domyślnie uruchomiony. Uruchommy serwer deweloperski i poznajmy go.

\n

Jeśli serwer nie jest uruchomiony, wystartuj go w ten sposób:

\n

Linux / macOS

Shell
$ python manage.py runserver\n
\n

Windows

Windows
...\\> py manage.py runserver\n
\n

Teraz otwórz przeglądarkę internetową i wejdź na „/admin/” swojej lokalnej domeny – na przykład http://127.0.0.1:8000/admin/. Powinieneś zobaczyć ekran logowania panelu administracyjnego:

\n\"Ekran\n

Jako że tłumaczenie jest domyślnie włączone, jeśli ustawisz LANGUAGE_CODE, ekran logowania zostanie wyświetlony w twoim języku (jeśli Django ma odpowiednie tłumaczenie).

\n
\n
\n

Wejście do panelu administracyjnegoLink to this heading#

\n

Teraz spróbuj się zalogować kontem superusera, które stworzyłeś w poprzednim kroku. Powinieneś zobaczyć stronę główną panelu administracyjnego Django:

\n\"Strona\n

Powinieneś zobaczyć kilka typów modyfikowalnej treści: grupy i użytkowników. Pochodzą one z django.contrib.auth, frameworka uwierzytelniania Django.

\n
\n
\n

Udostępnij aplikację ankietową do modyfikowania w panelu administracyjnymLink to this heading#

\n

Ale gdzie jest nasza aplikacja ankietowa? Nie wyświetla się na stronie głównej panelu.

\n

Jest do zrobienia jeszcze jedna rzecz: musimy powiedzieć panelowi, że obiekty Question mają interfejs administracyjny. Aby to zrobić, otwórz plik polls/admin.py i zmień go, aby wyglądał tak:

\n
polls/admin.py
\n
Python
from django.contrib import admin\n\nfrom .models import Question\n\nadmin.site.register(Question)\n
\n
\n
\n

Poznaj funkcjonalność wolnego panelu administracyjnegoLink to this heading#

\n

Kiedy już zarejestrowaliśmy Question, Django wie, że powinno być wyświetlane na stronie głównej panelu:

\n\"Strona\n

Kliknij w „Questions”. Jesteś teraz na stronie „change list” dla pytań. Ta strona wyświetla wszystkie pytania w bazie danych i pozwala wybrać ci jedno do zmiany. Jest tutaj pytanie „What’s up?”, które stworzyliśmy wcześniej:

\n\"Strona\n

Kliknij w pytanie „What’s up?”, aby je edytować:

\n\"Formularz\n

Rzeczy, na które należy zwrócić tutaj uwagę:

\n\n

Dolna część strony daje ci klika możliwości:

\n\n

Jeśli wartość pola „Date published” nie zgadza się z czasem, w którym stworzyłeś pytanie w Tutorialu 1, prawdopodobnie oznacza to, że zapomniałeś podać poprawnej wartości ustawienia TIME_ZONE. Zmień je, przeładuj stronę i sprawdź, że pojawia się poprawna wartość.

\n

Zmień „Date published” klikając skróty „Dzisiaj” i „Teraz”. Następniej kliknij „Zapisz i kontynuuj edycję”. Następnie kliknij w „Historia” w prawym górnym rogu. Zobaczysz stronę wylistowującą wszystkie zmiany dokonane na tym obiekcie przez panel administracyjny Django, z czasem i nazwą użytkownika osoby, która zrobiła zmianę:

\n\"Strona\n

Jeśli czujesz się dobrze z API modeli i zaprzyjaźniłeś się z panelem administracyjnym, przeczytaj 3. część tego tutoriala, aby dowiedzieć się jak dodać więcej widoków do naszej aplikacji ankietowej.

\n
\n
","rootId":"writing-your-first-django-app-part-2","toc":[{"title":"Konfiguracja bazy danych","anchor":"database-setup","children":[]},{"title":"Tworzenie modeli","anchor":"creating-models","children":[]},{"title":"Włączanie modeli","anchor":"activating-models","children":[]},{"title":"Zabawa z API","anchor":"playing-with-the-api","children":[]},{"title":"Wprowadzenie do panelu administracyjnego Django","anchor":"introducing-the-django-admin","children":[{"title":"Tworzenie konta administratora","anchor":"creating-an-admin-user","children":[]},{"title":"Uruchom serwer deweloperski","anchor":"start-the-development-server","children":[]},{"title":"Wejście do panelu administracyjnego","anchor":"enter-the-admin-site","children":[]},{"title":"Udostępnij aplikację ankietową do modyfikowania w panelu administracyjnym","anchor":"make-the-poll-app-modifiable-in-the-admin","children":[]},{"title":"Poznaj funkcjonalność wolnego panelu administracyjnego","anchor":"explore-the-free-admin-functionality","children":[]}]}],"breadcrumbs":[{"docname":"intro/index","title":"Pierwsze kroki","url":"/pl/6.0/intro/"}],"prev":{"docname":"intro/tutorial01","title":"Pisanie pierwszej aplikacji Django, część 1.","url":"/pl/6.0/intro/tutorial01/"},"next":{"docname":"intro/tutorial03","title":"Pisanie pierwszej aplikacji Django, część 3.","url":"/pl/6.0/intro/tutorial03/"},"formats":{"html":"/pl/6.0/intro/tutorial02/","markdown":"/pl/6.0/intro/tutorial02.md","json":"/pl/6.0/intro/tutorial02.json"},"source":"https://github.com/django/django/blob/stable/6.0.x/docs/intro/tutorial02.txt","official":"https://docs.djangoproject.com/pl/6.0/intro/tutorial02/","inVersions":["6.1","6.0","5.2","5.1","5.0","4.2","4.1","4.0","3.2","3.1","3.0","2.2","2.1","2.0","1.11","1.10"],"inLocales":["en","sv","zh-hans","ga","fr","ja","id","it","pt-br","ko","es","el","pl"]}