Skip to content
GitLab
Select Git revision
Search by author
  • Any Author
  • autociadmin autociadmin autociadmin
  • chenzeyuan chenzeyuan chenzeyuan
  • 余良海 余良海 yulianghai
  • 兰梦 兰梦 lanmeng
  • 冯春林 冯春林 fengchunlin
  • 刘华 刘华 liuhua
  • 刘壮 刘壮 liuzhuang
  • 刘杨 刘杨 liuyang
  • 刘涛 刘涛 liutao02
  • 刘涛 刘涛 liutao
  • 刘潇航 刘潇航 liuxiaohang
  • 刘硕 刘硕 liushuo
  • 刘祖强 刘祖强 liuzuqiang
  • 刘福涛 刘福涛 liufutao
  • 刘震宇 刘震宇 liuzhenyu
  • 唐鲁严 唐鲁严 tangluyan
  • 夏凯旋 夏凯旋 xiakaixuan
  • 奚云飞 奚云飞 xiyunfei
  • 孙檬 孙檬 sunmeng
  • 季炜 季炜 jiwei
20 authors
  1. Jul 31, 2013
  3. May 28, 2013
  5. Apr 25, 2013
  7. Apr 10, 2013
  9. Apr 09, 2013
  11. Apr 08, 2013
  13. Apr 01, 2013
  15. Mar 26, 2013
  17. Mar 22, 2013
  19. Mar 19, 2013
  21. Mar 18, 2013
  23. Mar 14, 2013
  25. Feb 26, 2013
  27. Feb 06, 2013
  29. Jan 25, 2013
    • Sami Kerola's avatar
      docs: usage function and gettext · 24f109e3
      Sami Kerola authored 
      I made following survey which was sent to all email addresses in po/
directory that had the on-going millenium as time when translator had
been active.

  There are two quite common styles to write a command usage print out,
  which one you prefer?

  1. Each option as separated translatable string.	18 votes
  2. Or the whole thing as one big output.		 1 vote
  3. No preference.					 1 vote

The questionaire had also free text field asking 'Why do you prefer
that?', and here are the answers.

  [Separately] It is easier to follow changes with the translations.  If
  you change only one line or two, the big string would change to fuzzy
  and I have to check the whole thing to see what was changed in the
  original.  If the changed line is a single string, the string to check
  is a lot shorter.

  [No preference] Usually, if there is no reason to separate strings,
  better keep them together so that the context is obvious.  In the case at
  hand, it might help if in some language e.g.  one translated line is too
  wide for the screen.  This is unlikely, but...  OTOH, with this solution,
  if you change one string the whole translation will be discarded until a
  translator comes and updates it...

  [Separately] It may be a bit harder to get the formatting right, but it
  is much easier in maintenance.  With one option changing, the
  translator immediately sees the spot.  And even with a lazy translator,
  program author will have all the options translated that have not
  changed at all.

  [Separately] First one would be more in elegant I believe

  [Separately] I prefer to have them separately because they don't form a
  single text paragraph.  In other words, they can be translated
  separately because they are complete and separate "sentences".  Of
  course consistency of format and word choices need to be taken care of,
  but the fact that the messages appear next to each other in the PO file
  should be enough.  Also if the options are not translated separately,
  adding or editing one option causes the translation of all options to
  become fuzzy and if for some reason it isn't checked before next
  release (happens sometimes), all of them will show untranslated to the
  user.

  [Separately] Translations are a lot easier to update that way.  If an
  option is added, removed or changed, only a small amount of text
  becomes fuzzy.  If everything is in one big output, a lot of text
  becomes fuzzy, and you have to read a lot more text to discover what
  exactly changed.

  [Separately] When updating a fuzzy translation, with one big output
  it's very tedious and error-prone to find out the reason for fuzziness,
  i.e.  what actually has changed in the msgid.

  [Separately] Way easier to translate, and especially to spot
  translation updates when one string gets removed, added or modified.

  [Separately] Makes translation memory more efficient.  Some hard terms
  in the list don't prevent translation of the whole block.  Actually the
  beginning of the strings don't need any translation ta all before []
  part.  Information about the context can be provided in comments or the
  context parameter.

  [Separately] Please consider the case when a part of string, (= msgid)
  is changed.  It is marked as fuzzy in the .po files, we translators
  have to check whole sentences for the difference between it and
  previous version.

  [Separately] Every sentence must be a separate translation unit.

  [One big output] for performance to ouput strings

  [Separately] In the second case, if only one option changes (or a new
  one is added), the translator will see as if all of the options
  changed, having to find out which one of them is really new or has
  actually changed.  Also, if the translator has had no time to update
  the string, only one of the options will be shown in the original
  language (which is arguably ugly, but better than nothing for many
  users).

  [Separately] It's easier to translate the options separately using
  translation memory.

  [Separately] Easier to separate and see changes

  [Separately] more translator friendly

  [Separately] From the user POV I found the separeted version more
  interesting because if a maintainer can't update the translation fast
  enough between releases the user will still get the current translated
  string with the new ones untraslated.  From the translator POV the big
  output will give more context information as one can see the whole
  command options.  With a new string added while the rest is translated
  having some context can be more difficult.

  [Separately] Additions to the list or changes to one options means you
  don't have to check all lines each time.

So unless you have very, _very_ good reason you should not output all
usage as one big table.  This implies also that when large usage output
is changed it should be split to small hunks.  That may be a bit more
work once, but the next change will pay the extrawork off so never
hesitate when splitting.

Reference: http://www.surveymonkey.com/s/QKZ75HK


Signed-off-by: default avatarSami Kerola <kerolasa@iki.fi>
      24f109e3
  31. Jan 09, 2013
  33. Dec 19, 2012
  35. Nov 27, 2012
  37. Nov 25, 2012
  39. Nov 22, 2012
  41. Nov 12, 2012
  43. Nov 07, 2012
  45. Oct 18, 2012
    • Karel Zak's avatar
      docs: update deprecated file · 2831866e
      Karel Zak authored 
      
The goal is to consolidate the very basic linux commands and minimize
dependence on another packages (e.g. shadow-utils). It seems better to
keep newgrp, vipw and vigr as non-deprecated for now. Maybe we will
found a way how to improve the code. We will see... :-)

Signed-off-by: default avatarKarel Zak <kzak@redhat.com>
      2831866e
  47. Oct 16, 2012
  49. Oct 15, 2012
  51. Oct 02, 2012
  53. Sep 05, 2012
  55. Sep 04, 2012
  57. Aug 15, 2012
  59. Aug 06, 2012
  61. Aug 03, 2012