@@ -11,7 +11,7 @@ msgid ""
1111msgstr ""
1212"Project-Id-Version :Python 3.14\n "
1313"Report-Msgid-Bugs-To :\n "
14- "POT-Creation-Date :2025-10-09 14:15 +0000\n "
14+ "POT-Creation-Date :2025-10-19 14:13 +0000\n "
1515"PO-Revision-Date :2025-09-16 00:00+0000\n "
1616"Last-Translator :python-doc bot, 2025\n "
1717"Language-Team :Polish (https://app.transifex.com/python-doc/teams/5390/pl/)\n "
@@ -1029,27 +1029,34 @@ msgid ""
10291029"Unicode code point, is to store each code point as four consecutive bytes. "
10301030"There are two possibilities: store the bytes in big endian or in little "
10311031"endian order. These two encodings are called ``UTF-32-BE`` and ``UTF-32-LE`` "
1032- "respectively. Their disadvantage is that if e.g. you use ``UTF-32-BE`` on a "
1033- "little endian machine you will always have to swap bytes on encoding and "
1034- "decoding. ``UTF-32`` avoids this problem: bytes will always be in natural "
1035- "endianness. When these bytes are read by a CPU with a different endianness, "
1036- "then bytes have to be swapped though. To be able to detect the endianness of "
1037- "a ``UTF-16`` or ``UTF-32`` byte sequence, there's the so called BOM (\" Byte "
1038- "Order Mark\" ). This is the Unicode character ``U+FEFF``. This character can "
1039- "be prepended to every ``UTF-16`` or ``UTF-32`` byte sequence. The byte "
1040- "swapped version of this character (``0xFFFE``) is an illegal character that "
1041- "may not appear in a Unicode text. So when the first character in a "
1042- "``UTF-16`` or ``UTF-32`` byte sequence appears to be a ``U+FFFE`` the bytes "
1043- "have to be swapped on decoding. Unfortunately the character ``U+FEFF`` had a "
1044- "second purpose as a ``ZERO WIDTH NO-BREAK SPACE``: a character that has no "
1045- "width and doesn't allow a word to be split. It can e.g. be used to give "
1046- "hints to a ligature algorithm. With Unicode 4.0 using ``U+FEFF`` as a ``ZERO "
1047- "WIDTH NO-BREAK SPACE`` has been deprecated (with ``U+2060`` (``WORD "
1048- "JOINER``) assuming this role). Nevertheless Unicode software still must be "
1049- "able to handle ``U+FEFF`` in both roles: as a BOM it's a device to determine "
1050- "the storage layout of the encoded bytes, and vanishes once the byte sequence "
1051- "has been decoded into a string; as a ``ZERO WIDTH NO-BREAK SPACE`` it's a "
1052- "normal character that will be decoded like any other."
1032+ "respectively. Their disadvantage is that if, for example, you use ``UTF-32-"
1033+ "BE`` on a little endian machine you will always have to swap bytes on "
1034+ "encoding and decoding. Python's ``UTF-16`` and ``UTF-32`` codecs avoid this "
1035+ "problem by using the platform's native byte order when no BOM is present. "
1036+ "Python follows prevailing platform practice, so native-endian data round-"
1037+ "trips without redundant byte swapping, even though the Unicode Standard "
1038+ "defaults to big-endian when the byte order is unspecified. When these bytes "
1039+ "are read by a CPU with a different endianness, the bytes have to be swapped. "
1040+ "To be able to detect the endianness of a ``UTF-16`` or ``UTF-32`` byte "
1041+ "sequence, a BOM (\" Byte Order Mark\" ) is used. This is the Unicode character "
1042+ "``U+FEFF``. This character can be prepended to every ``UTF-16`` or "
1043+ "``UTF-32`` byte sequence. The byte swapped version of this character "
1044+ "(``0xFFFE``) is an illegal character that may not appear in a Unicode text. "
1045+ "When the first character of a ``UTF-16`` or ``UTF-32`` byte sequence is "
1046+ "``U+FFFE``, the bytes have to be swapped on decoding."
1047+ msgstr ""
1048+
1049+ msgid ""
1050+ "Unfortunately the character ``U+FEFF`` had a second purpose as a ``ZERO "
1051+ "WIDTH NO-BREAK SPACE``: a character that has no width and doesn't allow a "
1052+ "word to be split. It can e.g. be used to give hints to a ligature algorithm. "
1053+ "With Unicode 4.0 using ``U+FEFF`` as a ``ZERO WIDTH NO-BREAK SPACE`` has "
1054+ "been deprecated (with ``U+2060`` (``WORD JOINER``) assuming this role). "
1055+ "Nevertheless Unicode software still must be able to handle ``U+FEFF`` in "
1056+ "both roles: as a BOM it's a device to determine the storage layout of the "
1057+ "encoded bytes, and vanishes once the byte sequence has been decoded into a "
1058+ "string; as a ``ZERO WIDTH NO-BREAK SPACE`` it's a normal character that will "
1059+ "be decoded like any other."
10531060msgstr ""
10541061
10551062msgid ""