Advanced PO file format #989

merged 2 commits into from May 23, 2012


None yet
3 participants

alanwww1 commented May 20, 2012

Using the new PO files in real life, I realized that it is not so easy for developers to check each time they add a string to the language file if that particular string has showed up already with another numeric id, but in another context.

In these cases we should have written some unique context message.

To solve this problem I came up with an idea of instead of storing the numeric id in a separate line, we could store it in the "msgctxt" line in the entry. This case we have a place for these ids AND we automatically have a completely unique context message for each msgid strings.

It is a one line change in the parser code, but of course the language files change massively.

Of course, if I am causing any troubles with pre-written PRs, Please let me know and I will convert those strings for you.

Please if there are no strong objections, I'd like to pull this in ASAP so that we finalize the format and finally, I can get the official Transifex project up and running. There is a great deal of requests coming from translators :-)

Thank you, Cheers, Attila

So a typical entry would look like this:

msgctxt "#7"
msgid "File manager"
msgstr ""

A full blown entry would look like this
(note you do NOT have to specify the reference and comment, just if you want to)

#. play GUI sounds
#: xbmc/settings/GUISettings.cpp
msgctxt "#34123"
msgid "Never"
msgstr "Soha"

JezzX commented May 21, 2012

Maybe this is just an english thing but wouldn't it be better this way

msgid "#7"
msgctxt "File manager"
msgstr ""

because the ID is a identification number
the TXT is actually the Text the string uses
and the STR is the translated string

also why do we need the # in it just seems like an extra character you need to type for no reason when it can just be msgid "7" simple to read that as its number 7 that the skin would use unless you can add other stuff for some od reason like msgid "#7 omg look what we have here"


alanwww1 commented May 21, 2012

Thanks for the comments. I was also thinking about these two points before:

  1. The whole gettext system relies on a unique msgid which is ALWAYS the source string. This is what it connects things together. Using a number here would totally screw things up, at the translation system in a way that translators would only see a number at the translatable field. Also using the source string at the msgid field ensures that in the future we'll be able to use non numeric-id based gettext calls, pluralized gettext calls and so on. So there is no real possibility to use the old xml id in the msgid field (at least we would loose the whole point of the system). The msgctxt field tuns to be an ideal place for it I think.
  2. Using a "#" character in the msgctxt fields befiore the numeric id, would be good, so that in the future, when we'll have non-numeric-id based calls possible, we could write an msgctxt message starting with any number. Maybe it is not so important, but this way the devs don't have to pay attention to this all the time.

JezzX commented May 21, 2012

OK so basically the reason is because that's the way the site works :) I can live with that.
Kind of curious about the "non numeric-id based gettext calls" and how that would work in the skin and add-ons when we use things like

<label>$LOCALIZE[6] $INFO[ListItem.Label]</label> 

But I guess that can be discussed in the forum and not a pull request

alanwww1 commented May 21, 2012

Thanks for the understanding in the format change.

About the text based gettext calls:

I'll make a big discussion period for that, when all things are working for translations.

We can find the best way to do things, which will be good for everyone.
Whatever we do, will be optional. So everyone will be able to use the numeric IDs if he prefers.
My first thought here, was to leave the numeric ID based calls for skins at least. But if we can find a good solution AND it makes skinners' life easier we can implement anything we found out.

But as I said I really plan to make a BIG discussion with the team on that. :-)



alanwww1 commented May 22, 2012

Can I pull this in, or should I wait for it until the merge window ?

My idea is to pull it in and I can help all other PRs to check and correct if the language files are ok in them, so that they get finalized until the new merge window is open.

For example I saw that Lars has an open PR with still XML files in them (LibCEC).

Thanks !


JezzX commented May 22, 2012

I'm personally on the side of its a bug fix for some previous commit it should go in as soon as possible but I don't make the rules and like you don't have much of a clue on what's set in stone and what's not.

Also I guess another "programmer" maybe needs to look over the code first since we have had a couple of false starts on this in the past month as well maybe @jmarshallnz or whoever else has commented in the past


jmarshallnz commented May 23, 2012

Agreed that this is a fix. I shall review the code today.

EDIT: change is trivial - feel free to pull.

alanwww1 was assigned May 23, 2012

alanwww1 merged commit 5b04c3d into xbmc:master May 23, 2012

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment