GNOME Bugzilla – Bug 670650
Be more translation friendly - avoid markup in translatable strings
Last modified: 2015-10-20 11:30:19 UTC
Hi awesome PiTiVi developers :) I'm currently reviewing the Catalan translation and I noticed that there are quite a few strings that are like "<b>SOMETHING</b>". It would be cool, as a lot of other projects have already done, to clean the markup that does not need to be on the translation so that we can keep the translations cleaner and also, and more interesting, we are not going to be able to break PiTiVi builds so easily (a "<b>SOMETHING<b>" can be a bit naughty :D Getting the current POT file from damned-lies[1] and grep'ing over the <b> strings will give you a hint on them. [1] http://l10n.gnome.org/POT/pitivi.master/pitivi.master.pot
100% agreed. I know about that kind of issue, and if you still encounter such things in the code please point them to me specifically. However, take note that the code in pitivi "master" is very old now, everything happens in the "ges" branch of the pitivi repository, so it's possible that your particular issue is already fixed... (I'm aware that the fact that it's in a separate branch is not optimal for translators!) If you feel like it, you could take a look at pitivi's ges branch with git grep and help me identify uncool strings that I missed :) if you need help, feel free to poke me on IRC.
This is what I see in pitivi git ges: git grep '_("<b>' pitivi mediafilespreviewer.py: "\n" + _("<b>Duration</b>: %s") % pretty_duration + "\n" mediafilespreviewer.py: _("<b>Duration</b>: %s") % pretty_duration + "\n" That's all... and in this particular case, given that the ending bold delimiter is not at the end, I'm not sure there is something to be done? So yeah, please point out the areas where it's still wrong and how exactly the string should be :)
If that's the only two strings that have "<b>" on it then it's fine. Btw. why the ges branch is not on git.gnome.org? From a l10n POV that's terrible, one day or another the branch (I see that is on a github repo) will be merged without any kind of notice and all the work we (as the GNOME l10n team) are doing on master will be completely wasted. The questions are just pilling up now that I'm aware of this branch ... Is there any good reason to develop on github and also keep the git.gnome.org repository? Could the PiTiVi team at least send a mail to the gnome-i18n@gnome.org mailing list telling us to not translate anymore the master branch? Is there any ETA on merging the branch back to git.gnome.org? Any releases expected from master (on git.gnome.org)? Thanks for all your work on this awesome program, but keep it also awesome for translators ;)
> why the ges branch is not on git.gnome.org? > I see that is on a github repo The git repositories are individuals' experimentation/WIP branches. The more "official" ges base branch is actually a branch on the main pitivi git repository (git://git.pitivi.org/git/pitivi.git). We do synchronize this with the git.gnome.org repo with git merges every so often, but in the case of the GES port branch this has fallen behind a bit indeed. The thing is that it's in a branch, rather than in pitivi master. Once it gets merged there, I would push the stuff to git.gnome.org too. The reason why it's not merged to master yet is that the ges port is still very much in development/a bit too broken to be mergeable to master just yet. I know what you mean here: that eventually there will be a big "code drop" into master and that it might mean that a bunch of strings suddenly get fuzzied, and that sucks for translators. However, if it can somehow reassure you: 1) I'm not sure how much the strings have deviated from master (do you have a trick to compare?), but my guess is "not that much" -- if they did, it's probably because I've been simplifying or merging redundancies. 2) The user manual is unchanged, except one commit I just pushed to master now. 3) I will merge the translations from gnome git to pitivi git master, so the translations changes that happened since 0.15 are not lost. That being said, should I still send an email to gnome-i18n saying "don't translate"? Sounds a bit strange to me; I don't really expect translators to jump on the "ges" branch (and I'm not sure how we would be merging the changes back, perhaps Thibault would know). > Is there any ETA on merging the branch back to git.gnome.org? The problem is that currently there is no clear ETA for merging "ges" back into "master" because we're blocked on a set of bugs in GES (the lib, not the branch)... and I need someone to fix those first. > Any releases expected from master (on git.gnome.org)? Stable releases will always come from master, if that's what you mean. And I'd love to get rid of the separate "ges" branch and merge back to master asap, but it's not stable enough, I think.
> The git repositories are individuals' experimentation/WIP branches. Oops, I meant the "github" repositories.
I have removed most of the markup in .ui files: http://git.gnome.org/browse/pitivi/commit/?id=9642092edb207c7eb8dd05b05c6a3471a058a014 There is still some left, because I don't know how to replace <big> etc. Also, there is a lot of markup in strings in .py files, but I have no programming knowledge whatsoever, so I couldn't fix these.
I have this notes to remove markup in .ui files: <i> - <attribute name="style" value="italic"/> <big> - <attribute name="scale" value="1.2"/> I think <small> would be like <big>, but using value="0.8" but I'm not 100% sure about it. Is there any documentation or reference manual about this?
Oh snap, I forgot about the existence of this particular bug report - renaming it for searchability. There are some issues I have raised as part of bug #706767, which I will now be marking as a duplicate of this. As illustrated in 706767, the core issue is that there seems to be no "attribute" in glade whose values I can set to "small", "big", etc.: glade will override/reset those if you set them. This is a dealbreaker as numeric values mean pretty much nothing to me, so I'd appreciate you guys finding out what's the proper way to do this. If there's actually a bug in glade there, you need to file a bug in glade and mark it as a dependency for this one...
*** Bug 706767 has been marked as a duplicate of this bug. ***
Maybe not really a bug in Glade, but if there is a GNOME Goal abut removing markup in .ui files, and these files are generated by Glade, we could file a bug against Glade to change it's behaviour about markup would be a good idea. About numbers in attributes, I know they are a bit rough, but I guess this is the only way to specify those values.
(In reply to comment #7) > I have this notes to remove markup in .ui files: > > <i> - <attribute name="style" value="italic"/> > <big> - <attribute name="scale" value="1.2"/> > > I think <small> would be like <big>, but using value="0.8" but I'm not 100% > sure about it. > > Is there any documentation or reference manual about this? https://mail.gnome.org/archives/desktop-devel-list/2012-May/msg00285.html This is all I got from developers when I tried to inquire this issue some time ago.
This has already fixed in Glade, so we could close this bug. Do you agree?
Daniel: fixed in which version of glade, where?
These are the two commits made in the master branch of Glade: https://git.gnome.org/browse/glade/commit/?id=06d14dce9ec631b0eaf76097bc6dcbbad09fe060 https://git.gnome.org/browse/glade/commit/?id=1fd9d318d3e60313ba33f9dc9000bfc4c8a3f182
Hmmm, I would rather depend on released versions of stuff, or, rather, I need to revisit this once I (and other contributors) switched to GNOME 3.10 for our daily development use...
Okay I'm confused now... is there something that remains to be done on the Pitivi side today, or is our code clean already?
Still there are some strings with markup, so maybe you should review them to try to remove the markup Thanks!
This bug has been migrated to https://phabricator.freedesktop.org/T2917. Please use the Phabricator interface to report further bugs by creating a task and associating it with Project: Pitivi. See http://wiki.pitivi.org/wiki/Bug_reporting for details.