1. 19 4月, 2018 7 次提交
    • D
      po: minimize language am · 2ee64e58
      Daniel P. Berrangé 提交于
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      2ee64e58
    • D
      po: minimize language af · 2ffcb25c
      Daniel P. Berrangé 提交于
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      2ffcb25c
    • D
      po: minimize & canonicalize translations stored in git · a3857dbe
      Daniel P. Berrangé 提交于
      Similar to the libvirt.pot, .po files contain line numbers and file
      names identifying where in the source a translatable string comes from.
      The source locations in the .po files are thrown away and replaced with
      content from the libvirt.pot whenever msgmerge is run, so this is not
      precious information that needs to be stored in git.
      
      When msgmerge processes a .po file, it will add in any msgids from the
      libvirt.pot that were not already present. Thus, if a particular msgid
      currently has no translation, it can be considered redundant and again
      does not need storing in git.
      
      When msgmerge processes a .po file and can't find an exact existing
      translation match, it will try todo fuzzy matching instead, marking such
      entries with a "# fuzzy" comment to alert the translator to take a
      look and either discard, edit or accept the match. Looking at the
      existing fuzzy matches in .po files shows that the quality is awful,
      with many having a completely different set of printf format specifiers
      between the msgid and fuzzy msgstr entry. Fortunately when msgfmt
      generates the .gmo, the fuzzy entries are all ignored anyway. The fuzzy
      entries could be useful to translators if they were working on the .po
      files directly from git, but Libvirt outsourced translation to the
      Fedora Zanata system, so keeping fuzzy matches in git is not much help.
      
      Finally, by default msgids are sorted based on source location. Thus, if
      a bit of code with translatable text is moved from one file to another,
      it may shift around in the .po file, despite the msgid not itself changing.
      If the msgids were sorted alphabetically, the .po files would have
      stable ordering when code is refactored.
      
      This patch takes advantage of the above observations to canonicalize
      and minimize the content stored for .po files in git. Instead of storing
      the real .po files, we now store .mini.po files.
      
      The .mini.po files are the same file format as .po files, but have no
      source location comments, are sorted alphabetically, and all fuzzy
      msgstrs and msgids with no translation are discarded. This cuts the size
      of content in the po directory from 109MB to 19MB.
      
      Users working from a libvirt git checkout who need the full .po files
      can run "make update-po", which merges the libvirt.pot and .mini.po
      file to create a .po file containing all the content previously stored
      in git.
      
      Conversely if a full .po file has been modified, for example, by
      downloading new content from Zanata, the .mini.po files can be updated
      by running "make update-mini-po". The resulting diffs of the .mini.po
      file will clearly show the changed translations without any of the noise
      that previously obscured content. Being able to see content changes
      clearly actually identified a bug in the zanata python client where it
      was adding bogus "fuzzy" annotations to many messages:
      
        https://bugzilla.redhat.com/show_bug.cgi?id=1564497
      
      Users working from libvirt releases should not see any difference in
      behaviour, since the tarballs only contain the full .po files, not the
      .mini.po files.
      
      As an added benefit, generating tarballs with "make dist", will no
      longer cause creation of dirty files in git, since it won't touch the
      .mini.po files, only the .po files which are no longer kept in git.
      
      To avoid creating a single commit 100+MB in size, each language is
      minimized separately in a following commit.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      a3857dbe
    • D
      po: stop storing libvirt.pot in git · d3034944
      Daniel P. Berrangé 提交于
      Storing the libvirt.pot file is a bad idea because it is an
      automatically generated file. Most patches will invalidate the stored
      libvirt.pot file by changing line numbers or introducing/removing files
      with translatable content.
      
      Anyone working with a libvirt GIT checkout who needs the libvirt.pot is
      better served creating a fresh copy with "make libvirt.pot".
      
      libvirt.pot is still included in the release dists, so those building
      from tarballs see no change in behaviour.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      d3034944
    • D
      po: add rules for integration with zanata · 4aaf5964
      Daniel P. Berrangé 提交于
      Add rules to handle pushing libvirt.pot to zanata, and refreshing .po
      files with new content from zanata.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      4aaf5964
    • D
      po: remove language list from zanata configuration · bdfdec31
      Daniel P. Berrangé 提交于
      The <locales> element in zanata.xml is no longer relevant as this info
      is recorded server side.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      bdfdec31
    • D
      po: provide custom make rules for po file management · c0a8ea45
      Daniel P. Berrangé 提交于
      Historically we have relied on autopoint/gettextize to install a
      standard po/Makefile.in.in. There is very limited scope for customizing
      this and it also causes a bunch of extra stuff to be pulled into
      configure.ac which potentially clashes with gnulib. Writing make rules
      for po file management is no more difficult than any other rules libvirt
      has, so stop using autopoint/gettextize.
      Reviewed-by: NJán Tomko <jtomko@redhat.com>
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      c0a8ea45
  2. 17 4月, 2018 1 次提交
  3. 10 4月, 2018 1 次提交
  4. 01 4月, 2018 1 次提交
  5. 23 3月, 2018 1 次提交
  6. 15 3月, 2018 1 次提交
  7. 05 3月, 2018 1 次提交
    • D
      Release of libvirt 4.1.0 · 6b59754b
      Daniel Veillard 提交于
      - docs/news.xml : updated for release
      - po/*.po*: regenerated
      
      Signed-off-by: Daniel Veillard<veillard@redhat.com>
      6b59754b
  8. 27 2月, 2018 1 次提交
  9. 22 2月, 2018 1 次提交
  10. 09 2月, 2018 2 次提交
  11. 31 1月, 2018 1 次提交
  12. 26 1月, 2018 1 次提交
  13. 19 1月, 2018 1 次提交
  14. 04 12月, 2017 1 次提交
  15. 03 11月, 2017 1 次提交
  16. 04 10月, 2017 1 次提交
  17. 25 9月, 2017 1 次提交
  18. 04 9月, 2017 1 次提交
  19. 02 8月, 2017 1 次提交
  20. 26 7月, 2017 1 次提交
    • P
      util: introduce virFileCache · ac3eb2ab
      Pavel Hrdina 提交于
      The new virFileCache will nicely handle the caching logic for any data
      that we would like to cache.  For each type of data we will just need
      to implement few handlers that will take care of creating, validating,
      loading and saving the cached data.
      
      The cached data must be an instance of virObject.
      
      Currently we cache QEMU capabilities which will start using
      virFileCache.
      Signed-off-by: NPavel Hrdina <phrdina@redhat.com>
      Reviewed-by: NJiri Denemark <jdenemar@redhat.com>
      ac3eb2ab
  21. 14 7月, 2017 1 次提交
  22. 11 7月, 2017 1 次提交
  23. 05 7月, 2017 1 次提交
  24. 07 6月, 2017 2 次提交
  25. 02 6月, 2017 1 次提交
  26. 26 5月, 2017 1 次提交
  27. 06 5月, 2017 1 次提交
  28. 19 4月, 2017 2 次提交
  29. 12 4月, 2017 1 次提交
  30. 02 4月, 2017 1 次提交
  31. 28 3月, 2017 1 次提交