Помилки в перекладах

[yurchor]

Не зовсім про помилки у перекладі, але...

Не дуже тямлю у gtk, тому прошу допомоги.

Володимире, як будете у цій гілці, чи не підкажете, можна отак вкладати left?

https://gitlab.gnome.org/GNOME/nautilus/-/blob/main/src/nautilus-file-operations.c#L5672

Бо люди скаржаться, що замість числового значення пише у вікно "#x27d файлів".

[yvs115]

Поки чекаєте на відповідь конкретної людини, напишу коротеньку відповідь

> можна отак вкладати left? https://gitlab.gnome.org/GNOME/nautilus/-/blob/main/src/nautilus-file-operations.c#L5672
>
  можна, чому ні, цілком стандартний С синтаксис:
- перший виклик ngettext("Preparing to move %'d file", "Preparing to move %'d files", left) поверне якийсь тестовий рядок відповідно до локалі і значення left
(нп для uk_UA.UTF-8 і left=1222333 це Підготовка до переміщення %'d файла)
- далі printf("Підготовка до переміщення %'d файла", 1222333) видасть текст з розділеним між тисячами числом відповідно до LC_NUMERIC

В сумі для printf(ngettext("Preparing to move %'d file", "Preparing to move %'d files", left), left)) отримаєте для left=1222333 тисячі з розділювачем " "
тобто "Підготовка до переміщення 1 222 333 файла"
(чи "файлів"?)

> Бо люди скаржаться, що замість числового значення пише у вікно "#x27d файлів".
>
  найбільш вірогідно це препроцесінг web чи іншого редактора,
  якщо є згенерований .mo/.po файл - можна перевірити чи там замість апострофа (') не прописано щось типу "Підготовка до переміщення %#x27d файлів"

[yurchor]

Автор звіту написав, що у найновішій версії все виправили. Гаразд, будемо чекати на оновлення. Дякую за консультацію.

[yvs115]

@yurchor
А чи не краще для пари "Sent/Received" буде "Надіслано/Отримано"?
Загальне "Передано" теж повністю зрозуміло, але в контексті "Надіслано n, отримано m" якось краще трохи

[yurchor]

@yurchor
А чи не краще для пари "Sent/Received" буде "Надіслано/Отримано"?
Загальне "Передано" теж повністю зрозуміло, але в контексті "Надіслано n, отримано m" якось краще трохи

Ціную вашу віру у мене, але, все ж, для полегшення завдання було б добре знати, де саме ви це бачите.

[yvs115]

Код: [Вибрати]

% ping 127.1
...
^C
Передано 5 пакетів, отримано 5, 0% packet loss, time 4074ms
...
в оригіналі transmitted, я думав що sent там поки не подивився, але все одно в перекладі краще Надіслано і отримано у цьому контексті
https://github.com/iputils/iputils/blob/master/po/uk.po#L1400

До речі й буде відповідати мануалу нп https://manpages.ubuntu.com/manpages/plucky/uk/man8/ping6.8.html
де по тексту використовується надіслано:
"... скільки пакетів було надіслано або отримано"
"Якщо було надіслано (і отримано) ..."

[yurchor]

Код: [Вибрати]

% ping 127.1
...
^C
Передано 5 пакетів, отримано 5, 0% packet loss, time 4074ms
...
в оригіналі transmitted, я думав що sent там поки не подивився, але все одно в перекладі краще Надіслано і отримано у цьому контексті
https://github.com/iputils/iputils/blob/master/po/uk.po#L1400

До речі й буде відповідати мануалу нп https://manpages.ubuntu.com/manpages/plucky/uk/man8/ping6.8.html
де по тексту використовується надіслано:
"... скільки пакетів було надіслано або отримано"
"Якщо було надіслано (і отримано) ..."

Ги-ги... і автор в обох перекладів один. Гаразд, як доберуться руки, повиправляю.

[yvs115]

> .. і автор в обох перекладів один. Гаразд, як доберуться руки, повиправляю.
>
  я знаю, й окреме дякую - за тей величезний обсяг перекладів (навіть не уявляю скільки на то часу треба).

p.s. якщо в пінгах буде правити, тут ще є в мануалі трохи (https://manpages.ubuntu.com/manpages/plucky/uk/man8/ping.8.html)
  але це чисто технічні ipicmp-ping нюанси не пов'язанні напряму з перекладом, - тому на розсуд чи треба

       Стандартне відхилення вибірки (mdev), по суті, середнє відхилення часу проходження сигналу
       від середнього часу проходження сигналу. Чим більшим буде mdev, тим більшою є зміна часу
       проходження сигналу (з часом). Якщо розкид часу проходження сигналу є великим, ви матимете
       проблеми зі швидкістю при передаванні великих масивів даних (таке передавання, якщо
       говорити строго, є довшим, ніж потрібно, оскільки зміна часу проходження, врешті,
       спричиняє потребу в очікуванні підтвердження на боці надсилання даних) і низьку якість
       інтернет-телефонії.

       Якщо було надіслано (і отримано) вказану кількість пакетів або якщо роботу програми було
       перервано сигналом SIGINT, буде виведено коротке резюме. Коротші поточні статистичні дані
       можна отримати без переривання процесу за допомогою сигналу SIGQUIT.

У першому і другому параграфах використовується загальний термін "сигнал", тоді як:
- у першому говориться про IP рівень - тобто про пакетний обмін у Інтернет мережі (на ICMP рівні використовується такий самий термін - пакет);
- у другому все гаразд - один з варіантів міжпроцесорної комунікації (включно з залізом) - сигнал (точно так як там і перекладено).

Тобто можна у першому замінити "сигнал" на "пакет" щоб було трохи ясніше (і плюс підкреслити різницю на що має вплив джитер [mdev])

       Cереднє відхилення часу проходження пакетів mdev - це по суті джитер в IP мережі.  Чим більшим буде mdev,
       тим більшим буде відхилення від середнього значення.  Якщо розкид часу проходження пакетів є великим,
       ви матимете, наприклад, як низьку якість інтернет-телефонії, так і проблеми зі швидкістю при передаванні
       великих масивів даних.  (таке передавання, якщо говорити строго, є довшим ніж потрібно, оскільки зміна часу
       проходження пакетів спричиняє потребу в додатковому очікуванні підтвердження на боці відправника).

       Якщо було надіслано (і отримано) вказану кількість пакетів, або якщо роботу програми було
       перервано сигналом SIGINT, буде виведено коротке резюме. Коротші поточні статистичні дані
       можна отримати без переривання процесу за допомогою сигналу SIGQUIT.