search

p-e-w / maybe

:open_file_folder: :rabbit2: :tophat: See what a program does before deciding whether you really want it to happen (NO LONGER MAINTAINED)
6.35k stars 163 forks source link

localization #28

Closed ghost closed 8 years ago

ghost commented 8 years ago

Hi. I added the gettext for localization and created a spec file for my OS. Next time if I will have time I will write some unittests. Have a nice day :)

coveralls commented 8 years ago

Coverage Status

Coverage increased (+0.3%) to 60.784% when pulling 93af835c79c2f1775fa739eecdbab10a26988a9e on hmikihth:master into 0111ef0e13471aabd2b2603efd6b24da9b6ac287 on p-e-w:master.

coveralls commented 8 years ago

Coverage Status

Coverage decreased (-15.5%) to 44.928% when pulling 6dd32e93edd2ee2b2b4d29949ade01f901f5b60f on hmikihth:master into 0111ef0e13471aabd2b2603efd6b24da9b6ac287 on p-e-w:master.

coveralls commented 8 years ago

Coverage Status

Coverage increased (+0.5%) to 60.938% when pulling 1315dcec271bb649d7843aae5ae6b1a3702ded64 on hmikihth:master into 0111ef0e13471aabd2b2603efd6b24da9b6ac287 on p-e-w:master.

p-e-w commented 8 years ago

I appreciate you taking the time to make these changes. Alas, I don't think I actually want localization at this point, and likely not in the future either. Localization adds enormous overhead and clutter to the repo, because we would have to ship translation files for each language and keep them updated. There are many changes coming up that would obsolete the translation immediately, and I for one prefer a program with English language output to one with incomplete and inconsistent translations.

maybe is a system tool, which often are not localized. I want to keep things as small, clean and clutter-free as possible, because the focus needs to be on correctness of the core functionality, not additional features.

As for the other points raised by your PR:

Thanks again for your efforts. Sorry this cannot be merged.

ghost commented 8 years ago

Hi.

I just made the localization for my distro. It is a Hungarian linux distro and most of the hungarians speak English very poorly. We dont need to translate for more languages. So many softwares does not have a hungarian translation and the distribution developers translate them, but much more difficult for them if there is no gettext integration. Most of the times just it is the only reason why they do not localize the softwares. So I dont agree with you in this. Yes the system tools sometimes are not localized, it is true.

I also started to modularize the syscall_filters.py but not ready to use yet. Maybe tonight i will finish that.

About the spec file. Yes that is not important.

Sent from my Fire

On 4 April 2016, at 18:16, Philipp Emanuel Weidmann notifications@github.com wrote:

I appreciate you taking the time to make these changes. Alas, I don't think I actually want localization at this point, and likely not in the future either. Localization adds enormous overhead and clutter to the repo, because we would have to ship translation files for each language and keep them updated. There are many changes coming up that would obsolete the translation immediately, and I for one prefer a program with English language output to one with incomplete and inconsistent translations.

maybe is a system tool, which often are not localized. I want to keep things as small, clean and clutter-free as possible, because the focus needs to be on correctness of the core functionality, not additional features.

As for the other points raised by your PR:

maybe uses py.test + tox for testing. I dislike Python's unittest builtin because it adds needless boilerplate. Just run tox to run the tests with coverage.Modularizing syscall_filters.py is a good idea and something that I am already working on (#26). I will keep filters and formatting together, though, and create a separate module for each concern (such as "delete" etc.). This will make it possible to allow some operations to pass via command line switches.I would be thrilled to see maybe packaged natively for some distros, but packaging files do not belong in the repo IMO. Distros typically maintain packaging metadata on their own servers and pull in the sources from a git tag as part of the build process. As with translation files, having packaging data in the core repo would just add noise to the directory and commit log that I am doing everything to avoid.

Thanks again for your efforts. Sorry this cannot be merged.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub

sanketplus commented 8 years ago

This project is open source for a reason @hmikihth , and since it is, you can fork and make your own Hungarian version of maybe :smiley: