1. 08 6月, 2020 1 次提交
  2. 04 6月, 2020 5 次提交
  3. 08 1月, 2020 1 次提交
  4. 07 1月, 2020 1 次提交
  5. 09 11月, 2019 2 次提交
  6. 18 10月, 2019 1 次提交
  7. 06 6月, 2018 1 次提交
  8. 19 4月, 2018 8 次提交
    • D
      po: attempt to fix srcdir != builddir builds · 655df055
      Daniel P. Berrangé 提交于
      The .pot, .po and .gmo files are slightly unusual in that we generate
      them in the srcdir when building form git. This is because they'll be
      bundled in the tar archive, so a build-from-tar will see them in srcdir.
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      655df055
    • D
      po: minimize language my · aa711c67
      Daniel P. Berrangé 提交于
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      aa711c67
    • D
      po: minimize language ga · 59b61454
      Daniel P. Berrangé 提交于
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      59b61454
    • D
      po: minimize language fur · e7bb87ae
      Daniel P. Berrangé 提交于
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      e7bb87ae
    • D
      po: minimize language fil · 24779716
      Daniel P. Berrangé 提交于
      Signed-off-by: NDaniel P. Berrangé <berrange@redhat.com>
      24779716
    • 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: 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: 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