For strings containing escaped newlines (\n), always start a new line
right before that sequence and remove any other whitespace in between.
Let the closing </string> tag follow immediately on the last line.
Keep one-line translations on one line, without arbitrary wrapping.
Actually fix some line-break inconsistencies within the translations
along the way. Some had questionable \n\ sequences, capitalized \N or
the n actually forgotten after an escaping backslash, which lead to
parsing errors. Others simply used two line breaks (which are
collapsed to one space during parsing) instead of the needed \n escape
sequence.
This gets the format much closer to what Weblate generates when
dumping the parsed strings into fresh XML files. Also harmonizes the
formatting in the "source" (English) values/strings.xml though.
Assuming that these are just input errors, as they don't exist in the
English strings and are not explicitly quoted.
Weblate will remove when outputting translated strings anyway.
The option "restartOnWakeup" was removed in Syncthing v1.21.0 [1]. Thus,
remove it from the Android app as well, since the option does not
perform any function anymore. In addition, update the Docs also [2].
[1] https://github.com/syncthing/syncthing/issues/8448
[2] https://github.com/syncthing/docs/pull/815
Signed-off-by: Tomasz Wilczyński <twilczynski@naver.com>
Co-authored-by: Tomasz Wilczyński <twilczynski@naver.com>
Bumps [com.google.guava:guava](https://github.com/google/guava) from
31.1-android to 32.1.2-android.
<details>
<summary>Release notes</summary>
<p><em>Sourced from <a
href="https://github.com/google/guava/releases">com.google.guava:guava's
releases</a>.</em></p>
<blockquote>
<h2>32.1.2</h2>
<h3>Maven</h3>
<pre lang="xml"><code><dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>32.1.2-jre</version>
<!-- or, for Android: -->
<version>32.1.2-android</version>
</dependency>
</code></pre>
<h3>Jar files</h3>
<ul>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/guava/32.1.2-jre/guava-32.1.2-jre.jar">32.1.2-jre.jar</a></li>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/guava/32.1.2-android/guava-32.1.2-android.jar">32.1.2-android.jar</a></li>
</ul>
<p>Guava requires <a
href="https://github.com/google/guava/wiki/UseGuavaInYourBuild#what-about-guavas-own-dependencies">one
runtime dependency</a>, which you can download here:</p>
<ul>
<li><a
href="https://repo1.maven.org/maven2/com/google/guava/failureaccess/1.0.1/failureaccess-1.0.1.jar">failureaccess-1.0.1.jar</a></li>
</ul>
<h3>Javadoc</h3>
<ul>
<li><a
href="http://guava.dev/releases/32.1.2-jre/api/docs/">32.1.2-jre</a></li>
<li><a
href="http://guava.dev/releases/32.1.2-android/api/docs/">32.1.2-android</a></li>
</ul>
<h3>JDiff</h3>
<ul>
<li><a href="http://guava.dev/releases/32.1.2-jre/api/diffs/">32.1.2-jre
vs. 32.1.1-jre</a></li>
<li><a
href="http://guava.dev/releases/32.1.2-android/api/diffs/">32.1.2-android
vs. 32.1.1-android</a></li>
<li><a
href="http://guava.dev/releases/32.1.2-android/api/androiddiffs/">32.1.2-android
vs. 32.1.2-jre</a></li>
</ul>
<h3>Changelog</h3>
<ul>
<li><a
href="https://redirect.github.com/google/guava/issues/6642#issuecomment-1656201382">Removed</a>
the section of our Gradle metadata that caused Gradle to report
conflicts with <code>listenablefuture</code>. (9ed0fa65ab)</li>
<li>Changed our Maven project to avoid <a
href="https://redirect.github.com/google/guava/issues/6654">affecting
which version of Mockito our Gradle users see</a>. (71a16d5a74)</li>
<li><code>collect</code>: Under J2CL, exposed <code>ImmutableList</code>
and <code>ImmutableSet</code> methods <code>copyOf</code> and
<code>of</code> for JavaScript usage. (b41968f5f2)</li>
<li><code>net</code>: Optimized <code>InternetDomainName</code>
construction. (3a1d18fbefa10218988a0fbbb6e1fada012397bf,
eaa62eb09548a6f1b7a757e21d8852724b631cab)</li>
</ul>
<h2>32.1.1</h2>
<h3>Maven</h3>
<pre lang="xml"><code><dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>32.1.1-jre</version>
<!-- or, for Android: -->
<version>32.1.1-android</version>
</tr></table>
</code></pre>
</blockquote>
<p>... (truncated)</p>
</details>
<details>
<summary>Commits</summary>
<ul>
<li>See full diff in <a
href="https://github.com/google/guava/commits">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
closes#1963
PS: This one has been kinda ugly to spot, ngl. I didn't expect that we
were modifying the welcome activity status bar color programmatically
instead of just with an XML theme ...
