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