Hide Forgot
Created attachment 826588 [details] incomplete german translation of /sbin/arp Description of problem: Case 1) Output strings of /sbin/arp are not fully translated to german strings. Address -> Adresse HWtype -> HW-Typ HWaddress -> HW-Adresse Mask -> Maske The rest of the words are fine in german too. Case 2) If a host is unreachable the output is correct to "unvollständig" but the count of spaces need one more space character. Maybe the problem here is the german character 'ä' is a special character and represents in Unicode maybe 2 bytes, so the algorithm to calculate the needed spaces afterwards is wrong? Version-Release number of selected component (if applicable): Fedora 20 Beta How reproducible: always Steps to Reproduce: 1. switch to german language 2. ping non-existing host in your subnet (e.g. 10.42.0.222) 3. /sbin/arp Actual results: Address HWtype HWaddress Flags Mask Iface xxx.xx.xxx.xxx ether xx:xx:xx:xx:xx:xx C p6p1 xxx.xx.xxx.xxx ether xx:xx:xx:xx:xx:xx C p6p1 xxxxxxxxxxxxxxxxxxxxxxx ether xx:xx:xx:xx:xx:xx C p6p1 xxxxxxxxxxxxxxxxxxxxxxx ether xx:xx:xx:xx:xx:xx C p6p1 xxxxxxxxxxxxxxxxxxxxxxx (unvollständig) p6p1 Expected results: Adresse HW-Typ HW-Adresse Flags Maske Iface xxx.xx.xxx.xxx ether xx:xx:xx:xx:xx:xx C p6p1 xxx.xx.xxx.xxx ether xx:xx:xx:xx:xx:xx C p6p1 xxxxxxxxxxxxxxxxxxxxxxx ether xx:xx:xx:xx:xx:xx C p6p1 xxxxxxxxxxxxxxxxxxxxxxx ether xx:xx:xx:xx:xx:xx C p6p1 xxxxxxxxxxxxxxxxxxxxxxx (unvollständig) p6p1 Additional info:
Created attachment 829263 [details] patch solving problem 1) I solved the problem 1). The strings Address, HWtype etc. were actually translated, but the .po file is quite outdated (the line numbers don't match) and the msgid was changed: "Address\t\t\tHWtype\tHWaddress\t Flags Mask\t\t Iface\n" - tabulators were replaced by spaces. I fixed this problem in all translations where it also occured, but maybe all the translations should be revised and updated. Problem 2) is more complicated, because the strings are printed with 'printf' function and the spaces needed are counted by '%<number>s' format. The printf function doesn't support multibyte characters afaik, so the printing mechanism probably needs to be redone, with some multibyte function counting the length used.
(In reply to jkoncick from comment #1) > I solved the problem 1). Pushed upstream, thanks. http://sourceforge.net/p/net-tools/code/ci/3eb367aedf1280f35105ede465c350a39b55fa91/ > Problem 2) is more complicated, because the strings are printed with ... Ok, I'll leave this BZ open.
Thank you for your great job.
For problem 2 maybe I have a hint. In the tool "df" there are also german special characters: 'ü' and 'ä' and 'ß' df Dateisystem 1K-blocks Benutzt Verfügbar Verw% Eingehängt auf /dev/sdb7 25671996 7529456 16815436 31% / devtmpfs 8168224 0 8168224 0% /dev tmpfs 8175184 2892 8172292 1% /dev/shm tmpfs 8175184 1092 8174092 1% /run tmpfs 8175184 0 8175184 0% /sys/fs/cgroup tmpfs 8175184 100 8175084 1% /tmp /dev/sda2 999320 124732 805776 14% /boot /dev/sdb8 23604668 1198952 21183624 6% /home df -hT Dateisystem Typ Größe Benutzt Verf. Verw% Eingehängt auf /dev/sdb7 ext4 25G 7,2G 17G 31% / devtmpfs devtmpfs 7,8G 0 7,8G 0% /dev tmpfs tmpfs 7,8G 2,9M 7,8G 1% /dev/shm tmpfs tmpfs 7,8G 1,1M 7,8G 1% /run tmpfs tmpfs 7,8G 0 7,8G 0% /sys/fs/cgroup tmpfs tmpfs 7,8G 100K 7,8G 1% /tmp /dev/sda2 ext4 976M 122M 787M 14% /boot /dev/sdb8 ext4 23G 1,2G 21G 6% /home But I don't know if the needed spaces are calculated or fixed.
How can I retrieve the homepages for unix/linux-commands such like arp, df, free, ... ? I'm also a programmer and would like improve some things (like these translations). But I don't know how to start. For me it is unclear how the way is: 1. I would develop in Fedora with it's repositories and send an improved version as bug report. Is this a good way or is a better way to go to the original homepage of a tool and download the latest source code? 2. To send them to the original project what steps I have to do? Some questions arise to this: a) How can I sure to develop with the latest (or nearly latest) source code? b) How can I sure, that the improved version is sending to a centralized place (homepage of that tool) and that other distros use that version? Because I think some tools are not synced between distros like Fedora and Ubuntu for a long time. Is where a solution to this or is this a general problem?
(In reply to Rolle from comment #5) > How can I retrieve the homepages for unix/linux-commands such like arp, df, > free, ... ? > I'm also a programmer and would like improve some things (like these > translations). But I don't know how to start. Great ! Good start is https://fedoraproject.org/wiki/Join If you can program than you can become a package maintainer yourself and help the community to fix bugs and implement new features and work with upstream (https://en.wikipedia.org/wiki/Upstream_%28software_development%29) so your work will eventually get into all distributions. https://fedoraproject.org/wiki/Join_the_package_collection_maintainers (the guidelines are quite big so don't panic during first read and ask me whatever you need to know). > For me it is unclear how the way is: > 1. I would develop in Fedora with it's repositories and send an improved > version as bug report. Is this a good way or is a better way to go to the > original homepage of a tool and download the latest source code? In most cases it's better and easier to use what's in Fedora and report bugs against Fedora, whereas the package maintainer knows the correct way how to report problems/sugestions upstream. To get the source of a package: # sudo yum install rpmdevtools yum-utils # yumdownloader --source <package> # rpmdev-setuptree # rpmbuild --recompile <downloaded src.rpm> Now see: ~/rpmbuild/SPECS for spec file (https://fedoraproject.org/wiki/How_to_create_an_RPM_package) ~/rpmbuild/SOURCES for upstream tarball plus whatever (patches) we add to upstream code ~/rpmbuild/BUILD for built code > 2. To send them to the original project what steps I have to do? Of course you can contact upstream directly, but different upstreams equals different policies so I can't give you general advice how to do that. You have to discover where it resides (Google is your friend), where is the code repository and how to report bugs/suggestions yourself. > Some questions arise to this: > a) How can I sure to develop with the latest (or nearly latest) source code? To be sure you have the latest code you need to know where the upstream has its repository and use that. But Fedora generally tries to include the latest releases so the code (generally) should not differ from upstream too much. (https://fedoraproject.org/wiki/Staying_close_to_upstream_project) > b) How can I sure, that the improved version is sending to a centralized > place (homepage of that tool) and that other distros use that version? > Because I think some tools are not synced between distros like Fedora and > Ubuntu for a long time. Is where a solution to this or is this a general > problem? We call that centralized place 'upstream' and if you report problems in this bugzilla the package maintainer should forward them upstream. It's better to use the package maintainer as a middleman because (s)he knows whether the problem is in upstream code or in something (patch) we add. You can't influence whether other distributions sync it, but they should do that in general. I put the reply here as it could be handy for somebody else, but please direct all other Fedora-related questions to my email to not pollute this bug. Or you can use http://webchat.freenode.net/?channels=#fedora-devel for your questions.
(In reply to Jiri Popelka from comment #6) > Of course you can contact upstream directly, but different upstreams equals > different policies so I can't give you general advice how to do that. > You have to discover where it resides (Google is your friend), ... Actually 'yum info net-tools | grep URL' should contain upstream URL. Upstream repo is http://sourceforge.net/p/net-tools/code/ci/master/tree/ You can clone it with git clone git://git.code.sf.net/p/net-tools/code net-tools-code
This message is a reminder that Fedora 20 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 20. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '20'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 20 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.