IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This way the custom rules for translating MIME types are used, and thus
the MIME type XML files are properly extracted.
Signed-off-by: Pino Toscano <ptoscano@redhat.com>
Weblate gets confused if the same email address is mentioned multiple
times in the translation headers. Dedupe authors so that each author
is mentioned only once, with a range of years listed.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Weblate works a slightly different way than Zanata. Instead of manually
pushing a pot file and fetching po files, Weblate is going to work
automatically with GitLab Merge requests. The main pot file must be
committed to git, and then Weblate fully manages the .po files, using
merge requests to send updates back.
With this new system we don't have a separate .mini.po file. The main
.po file is partially minimized by removing locations but does not
have non-translated msgids removed. This is not a big downside if we
consider that over time most translations should trend towards 100%
translated, and we have purged all 100% non-translated languages.
The main .pot file is generated with alphabetic sort ordering instead
of the default source file location ordering, as this makes the diffs
stable across renames/code movement, which is something we used in the
old .mini.po files.
The only rules needed in the makefile are to refresh the .pot file
and to generate the .gmo files at install time. We must never touch
the .po files locally, not even to rebase them when the .pot is
updated, as that will create merge conflicts with Weblate. Weblate
will take care of all rebases of the .po files in its own fork of
the git repo, and open merge requests to send changes back when
needed.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
There is no benefit to keeping .po files in git for languages which
have zero translated strings. make should also be honouring the list
in the LINGUAS file, not repeating it.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The project primary git repo has moved from pagure.io to
gitlab.com/virt-viewer/virt-viewer. We want users to submit
code contributions, bug reports and support questions to the
gitlab project, not the mailing list, nor bugzilla, nor the
virt-manager.org site.
We're still using virt-manager.org for hosting downloads of
source and pagure.io for MSIs, but we'll aim to change that
too.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Similar to the virt-viewer.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 virt-viewer.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
virt-viewer.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 Virt-Viewer 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.
Users working from a virt-viewer git checkout who need the full .po files
can run "make update-po", which merges the virt-viewer.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 virt-viewer 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.
The languages are minimized in the following commit since it is a
large mechanical process.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Add rules to handle pushing virt-viewer.pot to zanata, and refreshing .po
files with new content from zanata.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The <locales> element in zanata.xml is no longer relevant as this info
is recorded server side.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Historically we have relied on intltool to install a standard
po/Makefile.in.in which has very limited scope for customization.
intltool is deprecated in favour of standard gettextize tools,
but these share the same disadvantages.
Writing make rules for po file management is no more difficult
than any other rules virt-viewer has, so stop using intltool
and don't use gettextize ether.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The motivation for this dialog started with rhbz #1310624, where it was
reported that foreign menu was causing too many debug messages to be
printed to the console, because remote viewer had a timeout of 5 seconds
to refresh the ISO list automatically.
As a workaround, the timeout was adjusted for 5 minutes, but it could
cause more problems, such as inconsistencies between what was shown by
remote viewer and what the server had configured.
Another issue caused by displaying the ISO files as a menu item was that
if the list was too long, it would take all the available space on the
screen. In the end, a menu item was not the correct choice of UI
component for this use case.
In order to solve both problems, we now present the ISO list as a
dedicated dialog, where the refresh of ISO list is triggered manually by
the user and the list is contained within the dialog, by displaying de
files in a treeview.
Signed-off-by: Eduardo Lima (Etrunko) <etrunko@redhat.com>
Adds metadata to be used with Gnome Software.
Includes name, summary, description and a few screenshots of remote-viewer.
Signed-off-by: Lukáš Venhoda <lvenhoda@redhat.com>
Acked-by: Daniel P. Berrange <berrange@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
I'd like to keep our resources all in the same place. In the future we
will be able to have:
$(srcdir)
|_ resources
|_ ui: for our {remote,virt}-viewer ui specific files
|_ gtk: for files that can be automatically handled by Gtk (like
| app-menu).
|_ css: for custom themes (like:
https://bugs.freedesktop.org/show_bug.cgi?id=94276)
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
When using GtkApplication, Gtk automatically searches for the menus of
the application at "org/example/app/gtk/menus.ui".
Currently we don't have a "menus.ui", but try to see this commit is a
first step in order to use app-menu.
For now, let's standardize that all our UI files will have the ".ui"
extension instead of the ".xml" one.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
This dialog will show the progress of files being transferred from the
client to the guest and allows the user to cancel ongoing file transfer
tasks. The user can cancel each transfer individually, or cancel all
ongoing transfers at once.
Resolves: rhbz#1332180, rhbz#1324521
Signed-off-by: Jonathon Jongsma <jjongsma@redhat.com>
Acked-by: Fabiano Fidêncio <fidencio@redhat.com>
A few more pieces of old compatibility code can be dropped, as we
already depend on GLib 2.38.
Signed-off-by: Fabiano Fidêncio <fidencio@redhat.com>
Acked-by: Jonathon Jongsma <jjongsma@redhat.com>
Notify user, that VNC does not provide uuid.
Set uuid to string "VNC does not provide guid".
This is more informative then just plain "Unknown".
User will now know WHY the GUID is unknown, when using remote-viewer.
Push new pot with
cd po
make virt-viewer.pot
zanata push
Pull new translations with
cd po
zanata pull
Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
When user starts virt-viewer without specifying VM domain name
or with a wrong name a list of running machines is shown
and user may choose one of them.
When a user tries to connect to ovirt without specifying
VM name (remote-viewer ovirt://ovirt.example.com) or with
wrong VM name a list of available virtual machines is shown,
and the user may pick a machine he wants to connect to.
Unfortunately, I don't see yet how we could avoid the browser dialog
asking which application to open. On Firefox, each user has a
mimeTypes.rdf, but we can't really modify it..
