Update Polish translations

[balansczerni]

Contribution guidelines

• I've read the contribution guidelines and wholeheartedly agree

Language availability

• I've checked the list of available languages

Translations

{% macro t(key) %}{{ {
  "language": "pl",
  "action.edit": "Edytuj tę stronę",
  "action.skip": "Przejdź do treści",
  "action.view": "Zobacz kod źródłowy tej strony",
  "announce.dismiss": "Nie pokazuj tego ponownie",
  "blog.archive": "Archiwum",
  "blog.categories": "Kategorie",
  "blog.categories.in": "",
  "blog.continue": "Czytaj dalej",
  "blog.draft": "Wersja robocza",
  "blog.index": "Powrót do indeksu",
  "blog.meta": "Metadane",
  "blog.references": "Powiązane łącza",
  "clipboard.copy": "Kopiuj do schowka",
  "clipboard.copied": "Skopiowano do schowka",
  "consent.accept": "Akceptuj",
  "consent.manage": "Zarządzaj ustawieniami",
  "consent.reject": "Odrzuć",
  "footer": "Stopka",
  "footer.next": "Następna strona",
  "footer.previous": "Poprzednia strona",
  "header": "Nagłówek",
  "meta.comments": "Komentarze",
  "meta.source": "Kod źródłowy",
  "nav": "Nawigacja",
  "readtime.one": "Czas czytania: 1 min",
  "readtime.other": "Czas czytania: # min",
  "rss.created": "Kanał RSS",
  "rss.updated": "Kanał RSS zaktualizowanych treści",
  "search": "Szukaj",
  "search.placeholder": "Szukaj",
  "search.share": "Udostępnij",
  "search.reset": "Wyczyść",
  "search.result.initializer": "Inicjowanie wyszukiwania",
  "search.result.placeholder": "Zacznij pisać, aby szukać",
  "search.result.none": "Brak wyników wyszukiwania",
  "search.result.one": "Wyniki wyszukiwania: 1",
  "search.result.other": "Wyniki wyszukiwania: #",
  "search.result.more.one": "1 więcej na tej stronie",
  "search.result.more.other": "# więcej na tej stronie",
  "search.result.term.missing": "Brak",
  "select.language": "Wybierz język",
  "select.version": "Wybierz wersję",
  "source": "Przejdź do repozytorium",
  "source.file.contributors": "Kontrybutorzy",
  "source.file.date.created": "Utworzony",
  "source.file.date.updated": "Ostatnia aktualizacja",
  "tabs": "Zakładki",
  "toc": "Spis treści",
  "top": "Powrót do góry"
}[key] }}{% endmacro %}

[kamilkrzyskow]

Hi @balansczerni,
I've planned to post a PR, but you've posted the issue sooner, so I'll send you my differences. To cross check / discuss:

"blog.draft": "Wersja robocza", 
# Better since this translation of Draft is more widely used in sites like Gmail etc.
# and at least to me, "Szkic" is closer connected to images than to documents.

"blog.index": "Powrót do indeksu", 
# "Powrót" to align with "top" setting without a call to action, 
# as for your "Spis" translation I'm not sure if my is better, I would have to look on more examples.

"blog.references": "Powiązane łącza", 
# I chose "łącza" since later the site will surely add support for "Permanent link" translation 
# which is of course "Stałe łącze", so more future-proof to keep the terminology the same

"readtime.one": "Czas czytania: 1 min",
"readtime.other": "Czas czytania: # min", 
# I like your more succinct version more 🤔 

"rss.updated": "Kanał RSS zaktualizowanych treści", 
# In the German version it's "RSS Feed der aktualisierten Inhalte", 
# and I believe that the author is German, so my translation seems to be more accurate. 
# Can't really check without Insiders, how it's used.

"source.file.contributors": "Kontrybutorzy", 
# Here I'm not so sure either if it's better, than your "Współtwórcy" or "Współpracownicy". 
# But I've researched it a bit, and "Kontrybutorzy" is in fact used in technical documentations 
# like the one from IBM, so please state your stance on this.

[kamilkrzyskow]

As for further discussion @balansczerni:

"blog.categories.in": "w",

In Polish there is a similar word choice with w and we as there is with a and an in English. Based on another word we should be used instead of w. I considered to leave it as empty at first "", to only keep the categories, but then again w is a good enough compromise that will fit most cases.

What are your thoughts on this?

[kamilkrzyskow]

Also there is a typo in "readtime.one": "1 min czytnia",. It should be czytania just like in "readtime.other": "# min czytania",

[squidfunk]

I'm happy to update the translations when you found consensus 😊

[balansczerni]

I think Kamil's (@kamilkrzyskow) corrections are very good and should be implemented.

The "blog.categories.in": "w", issue is actually very debatable, and either using "w" or an empty "" would be fine.

I wouldn't use "we" because it may sound archaic (although probably in some narrow usages it would be more correct) and "w" is more universal.

On the other hand, an empty "" string solves this dilemma. Similar solutions are also common on the Polish web.

[squidfunk]

Perfect! Could you adjust your OP then to include his translations?

[kamilkrzyskow]

I think Kamil's corrections are very good and should be implemented.

Thanks for the feedback. Even though I liked your version of readtime, a little bit more, I'm happy you've chosen my version @balansczerni 😃 Edit: I see it follows the style of search.result translation, that wasn't my intention😅, but turned out well.

I checked that the adjusted OP doesn't have any issues, and is ready for merge @squidfunk.
I've noticed that you're not attributing people in the commits (aka coauthoring), I don't know if it's a limitation of git which blocks inputting usernames that aren't in the git history or if you're deliberately choosing not to do so. Maybe that's my naivete, and big repositories with a lot of PRs / Issues just work like that to save time 🤔, which is sad. Edit2: I don't want to come of as some "contribution hunter" or whatever, attribution should go to the OP, since my input was just a sanity check, I just noticed something that's been bugging me, so I commented on it.

[squidfunk]

I've noticed that you're not attributing people in the commits (aka coauthoring), I don't know if it's a limitation of git which blocks inputting usernames that aren't in the git history or if you're deliberately choosing not to do so. Maybe that's my naivete, and big repositories with a lot of PRs / Issues just work like that to save time 🤔, which is sad. Edit2: I don't want to come of as some "contribution hunter" or whatever, attribution should go to the OP, since my input was just a sanity check, I just noticed something that's been bugging me, so I commented on it.

I haven't done that so far, not because I intend to, but I don't think it's possible without a PR. For what I know you need to know the email addresses of the users co-authoring, which makes it impossible since most don't have a public email address. Thus, it would need to be done in a PR. Of course, we're accepting PRs for translation updates, but the history shows that the current approach using issues is much easier for users to contribute. However, without a PR, I'm not sure it's possible to set co-authors.

If you like, you can create a PR with the changes in this issue, and I'll merge it. No problem! We can even add a checkbox that says "I would like to create a PR for this myself", or something like that. Great feedback!

If it's possible by using GitHub usernames, I'd be happy to learn how 😁

[squidfunk]

On another note, it's important to know that there was communication overhead in the past when users submitted PRs to update translations. This was mainly due to several fields are given "special treatment", because they are needed to configure other parts of the theme, like search. Our contribution guide explains which fields must not be changed, but they were included nonetheless. You can check past PRs – there's more communication overhead involved.

Thus, our aim with the new process is only to make it as simple as possible to complete the missing translations. If we can somehow do it in a way where the original authors are attributed, I'd be happy to follow the process.

[kamilkrzyskow]

As for the, email matter, GitHub provides private emails to the users, which are built from a combination of their ID and username. I admit, I don't know if they're enabled by default for each user, or if it's a opt-in setting.

You say it's impossible without a public email, and the only other option is to do it via PR, but I missed this information.

123209821+balansczerni@users.noreply.github.com this should be the GitHub email of OP, so if it's alright with you, please try to coauthor the commit with this email, if not then do as you like.
I've sent the PR #4957

---

As for the other matter, it's not about me getting the PR or attribution, I just had a concern. I admit that it maybe escalated too much after seeing #4925 where you had access to the commit and the email within to properly attribute, or after seeing https://github.com/squidfunk/mkdocs-material/pulse/monthly where your commits with the auto-generated files create this strange contribution unevenness. So all of my concerns are based on a short snapshot, I've seen during the last 2 days.

I'm not denying any of your work, I know that you're the driving force of this project, and that you've committed most of the source code, and I'm grateful for that, and I just found it weird comparing it to other repositories where I've seen a more evenly distributed contribution chart, which contributed to my confirmation bias.

Maybe that is your workflow that works for you based on experience with dealing with previous PRs etc., I'm not in a position to say it's wrong or that it should be changed, I just gave my 2 unsolicited cents on the matter.

[kamilkrzyskow]

🤔 I've changed my mind, since you asked me for the PR, I've sent the PR while attributing @balansczerni.
#4957

[squidfunk]

Thanks!

As for the other matter, it's not about me getting the PR or attribution, I just had a concern. I admit that it maybe escalated too much after seeing #4925 where you had access to the commit and the email within to properly attribute, or after seeing https://github.com/squidfunk/mkdocs-material/pulse/monthly where your commits with the auto-generated files create this strange contribution unevenness. So all of my concerns are based on a short snapshot, I've seen during the last 2 days.

The problem is that we're now getting updated translations so fast that I have trouble updating them before other users do work that has already be done. FWIW, we've received 2x French and Spanish, as the "# missing translations" in the docs is automatically computed from the present ones. This is why I felt that moving fast here potentially losing attribution is more important than work being done multiple times. However, I understand that this may upset some users.

We'll add a contributing guide how to provide translation updates via PRs, and add a note + checkbox to the translation update form that asks the user if he wants to create a PR. If so, we won't use the code. I think that should work.

Other than that, I'll check if co-authoring works by using the generated email address. Where can I get that from?

[kamilkrzyskow]

Here you can check the users ID @squidfunk: https://api.github.com/users/squidfunk

I don't know if there is a GitHub UI endpoint, where it's generated, sorry. I only know about that ID+username combination and the @users.noreply.github.com is taken from my GitHub profile 😅

And yes, I've seen the 7+ translations issues during the 24h after the new way was introduced. The 2 Spanish translations were different from each other, I don't know Spanish, so I don't know if it was a difference based on Spanish and Latin American variant or something else entirely 🤷 and I've seen all of the versions that kept the ◀️ symbol in the strings. I understand that the change was very effective in getting translations, and also reveled some shortcomings of this approach.

I don't know if this will be an issue with CORS / if the GitHub API allows for that, but can't you block / hide the "Missing translations" indicator after someone adds a new Issue, and replace it with "Pending translation" and the link to the Issue?

[squidfunk]

Yes, I know of the GitHub API. I was asking for a simpler approach but I certainly can ask the GraphQL API for that. I just tried the co-authoring and it doesn't seem to work, or I'm doing something wrong. See this commit.

This should only be a temporary issue now that there are so many languages with missing translations. And no, I don't think investing time into adding logic to query GitHub issues from the browser of the user for pending translations is worth it. Yes, those translations were a little different and some users forget to remove the arrows, so there always manual work involved. Also, if you check your PR, you'll see that you also didn't follow the contributing guide.

To sum up: no, it is definitely not simple to come up with a process that works for all users. You seem to be very versed with git, but please don't forget that there are many users of Material for MkDocs that are rather non-technical and have trouble interacting with git. This is exactly why I wanted to make this process as simple as possible. If you're versed, you can of course create a PR, but we don't want to miss out on translations from those users that have trouble. It is not perfect and has its shortcomings, yes, but it is much easier than requiring the user to check out the source and edit .po files.

[kamilkrzyskow]

Yes, I do agree with every point you've made, that it's currently the short translation phase, and it will pass, so there is no need for an overly complex solution, and that giving people that are less "tech savy" with git etc., a way to contribute is a great approach.

As for me being well versed with git, I won't lie, I just know pure fetch, pull, and commit, the rest is done via IDE magic.

git -c credential.helper= -c core.quotepath=false -c log.showSignature=false commit -F C:\Users\HRY\AppData\Local\Temp\git-commit-msg-.txt "--author=balansczerni <123209821+balansczerni@users.noreply.github.com>" --
[update-pl-lang2 98ac179] Updated Polish translations
 Author: balansczerni <123209821+balansczerni@users.noreply.github.com>
 1 file changed, 13 insertions(+), 1 deletion(-)

This is the generated command, and I see that your 5f39cfb commit, doesn't follow the USERNAME <EMAIL> pattern, just the EMAIL.

git commit --author "evetion <8655030+evetion@users.noreply.github.com>"

A simplified version of the command for the commit

Maybe my previous message mislead you, since I was only talking about the ID+NAME combo, and I'm sorry if that's the case.

Then again in the link you've posted above https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors#creating-co-authored-commits-on-github , it says about the noreply addresses and talks about the pattern too.

So I think that in case of that commit Co-authored-by: evetion <8655030+evetion@users.noreply.github.com> would be a working description.

[evetion]

I'm happy with the attempt to credit me 👍🏻. To make this easy, maybe we should update the template with a field, if you want to be credited, please add your name+email here.

[kamilkrzyskow]

Good idea with the additional field, something similar was mentioned during this discussion.

I'm sorry that, this whole thing took so much back and forth... At first I was completely oblivious to the possibility of me doing the PR and coauthoring, and I didn't consider that @squidfunk doesn't know about the private noreply GitHub emails. This whole discussion could be avoided if I just gave specific instructions about my idea, instead of just commenting that he didn't do something the way I envisioned it. 😓

[squidfunk]

Co-authored-by: evetion 8655030+evetion@users.noreply.github.com

Jup, this works, thanks! No worries, I've now learned how to do co-authored commits, which is awesome. Proper attribution is definitely something worth giving for the time invested.

[squidfunk]

Resolved via 3104df5.

[squidfunk]

Released as part of 9.0.9