Add translations to everything #1973
Conversation
|
One issue here is that the translation files will be shared between the viewer and the servers. That's a problem because both the RPMs and debs have things split up in separate packages. @JoachimFalk and @grulja, do you have any suggestions or preferences here? Any other packages with the same structure that we can mimic? |
|
Hi, I don't think that would be a problem from the packaging point of view. There are two options for Fedora/RHEL:
I don't know any other package that would have to deal with similar problem, but I can imagine it's done in similar fashion as I wrote above. |
|
At the moment, translation are only contained in tigervnc-viewer. But, in Debian, we have tigervnc-common, which tigervnc-tools (vncpasswd, etc.), tigervnc-scraping-server, tigervnc-standalone-server, tigervnc-xorg-extension, and tigervnc-viewer all depend upon. The common translation would probably go into tigervnc-common if you do not intend to also provide a common library package for which these translations are and which you also considered to be user consumable, i.e., has public headers and you would consider to be usefull to others. At the moment, the common library code is not made available as a package or even installed as a static lib in the client or server packages. |
|
Thanks! Sounds like a -common package is the way to go. |
CendioOssman
force-pushed
the
translation
branch
6 times, most recently
from
5061600 to
f54ce94
Compare
p_() is commonly used for plural, whilst C_() is what's used by e.g. glib (and hence Gnome). Let's try to follow what most people are doing.
This will allow us to translate messages from the common library as well.
Make sure we don't have any race between setting up translations and using them by having them be implicitly loaded on first use.
The translations might use POSIX extensions to the format strings, which means we may need the gettext versions of the printf() functions where we don't directly control the format string.
We don't use this yet, but let's add it so we have the exact same set as glib, to keep things familiar.
We don't use these yet, but let's make sure the infrastructure is in place if we want to use it in the future. This should mean we have complete gettext support.
It's not clear when this should be used and not info(), so let's just remove the confusion.
To make life easier for the translators.
To make things more familiar for users.
Match what we are already doing in vncviewer.
Match what we are already doing in vncviewer.
They might be generated, so we need to make sure the parameter object retains its own copy of them.
This follows a standard pattern, so let's avoid having to duplicate it.
We have no intention of modifying this string.
These have historically been ASCII, but let's be prepared for more.
Now that we translate everything, we need to make sure the translations are included.
Let's reduce the number of packages we have a bit by merging the shared stuff.
Since every component of TigerVNC is now translated, not just the viewer.
CendioOssman
force-pushed
the
translation
branch
from
f54ce94 to
58fdd13
Compare
Currently, only the native viewer is translated. However, a lot of text the user sees also comes from the common library code.
There are also other components in the project that should be translated for users.
This PR moves the translation infrastructure to the common libraries, and tags everything for translation.