[07:07] <zbenjamin> didrocks: you here :D
[07:13] <didrocks> zbenjamin: yep! :)
[07:13] <didrocks> hey
[07:22] <zbenjamin> didrocks: hey sorry, i was on holiday
[07:24] <didrocks> zbenjamin: no worry! I hope you enjoyed them :)
[07:24] <zbenjamin> didrocks: yeps :D it was good
[07:30] <zbenjamin> didrocks: i saw you spent some quality time with the sdk
[07:35] <didrocks> zbenjamin: heh, quite some yeah :)
[07:35] <didrocks> zbenjamin: so, is my conclusion correct, you need to fiddle yourself with subdirectories?
[07:36] <didrocks> zbenjamin: so doing something like this: https://github.com/didrocks/splitthebill/commit/11fd9cd1d399539597f186b5e94ef207abfdd986
[07:46] <zbenjamin> didrocks: yes, thats your responsibility with all qmake projects
[07:47] <didrocks> zbenjamin: not really dev friendly I guess, especially as the ide is adding them directly (see the deletions)
[07:47] <zbenjamin> didrocks: thats true. But you can not assume that srcdir == installdir.
[07:48] <zbenjamin> I guess they just wanted to assume nothing
[07:54] <didrocks> zbenjamin: in some way, they do assume that even if you put files in a subdirectory, you want a flat structure when deploying though
[07:54] <didrocks> (which IMHO makes less sense that leaving files with the same dir structure)
[07:59] <kenvandine> rpadovani, looking forward to falldown hitting the store!
[08:29] <zbenjamin> didrocks: yeah for QML at least
[08:29] <zbenjamin> didrocks: there should be proper QML support in qmake
[08:31] <didrocks> agreed :)
[10:47] <nik90> zsombi: ping
[11:09] <zsombi> nik90: ong
[11:09] <zsombi> p
[11:09] <nik90> ongp?
[11:11] <zsombi> p+ :D
[11:11] <zsombi> nik90: so, whazzup?
[11:12] <nik90> zsombi: I need some brainstorming help with https://bugs.launchpad.net/ubuntu-clock-app/+bug/1488439
[11:12] <nik90> zsombi: shouldn' the listview automatically update when the data model changes?
[11:13] <nik90> it should be a Notifyable  property informing qml of the changes made to the backend and update the labels? Or do I have to manually call for alarmModel refresh() ?
[11:13] <zsombi> nik90: yes, it should, the only reason it doesn't may be that the date chaneg doesn't seem to be reported as position change on the alarm cache...
[11:13] <nik90> hmm, anyway I can detect this?
[11:14] <nik90> like using onModelReset or any other signal?
[11:14] <zsombi> nik90: if you don't get any signal from the ListView, then the cache did not refresh
[11:14] <zsombi> nik90: I think that one...
[11:15] <nik90> ok, so in the alarm list page, I will have onModelReset: refresh() to recreate the cache.
[11:29] <nik90> zsombi: https://code.launchpad.net/~nik90/ubuntu-clock-app/fix-alarm-list-refresh/+merge/269047
[12:20] <zsombi> nik90: nice :)
[12:22] <nik90> zsombi: the one minor inconvenience was that I had to pass the entire alarmModel to the edit alarm page as an argument. Although that's fine I suppose
[12:23] <zsombi> nik90: it is, as long as the model exists till teh entire lifetime of the page, beside, it only passes the reference, doesn't copy the model, so... :)
[12:24] <nik90> zsombi: indeed. I need to be careful about when I refresh the alarmModel indeed. We just fixed https://bugs.launchpad.net/bugs/1487789 few days back that scared the shit out of me.
[12:24] <zsombi> :D
[12:24] <zsombi> popey: ^^^ nik90 fixed the bug ;)
[12:25] <popey> zsombi: nik90 is awesome.
[12:25] <nik90> lol :D
[12:25] <zsombi> we knew that ;)
[12:25] <nik90> oh stop it guys ;)
[12:26] <zsombi> t1mp: could you give an eye one more time on the cppAbstractButton MR pls?
[12:26] <zsombi> kalikiana: ^
[12:26] <zsombi> you as well
[12:27] <nik90> zsombi: could you quickly add a comment approving the MR from a code-review perspective. I can then get it merged later today.
[12:40] <zsombi> nik90: I don' thave right to approve it, but yes, I can comment
[12:41] <maggots> anyone alive
[12:42] <zsombi> nik90: commented
[12:42] <nik90> zsombi: thnx, I or bartosz can top-approve once we do some more manual testing.
[12:42] <zsombi> evrrybody is alive :)
[12:43] <t1mp> zsombi: normally, an app dev would set onTriggered: {...} for an AbstractButton, and not override the trigger() function, right?
[12:44] <zsombi> t1mp: yes...
[12:45] <zsombi> t1mp: but, if you want to override the default trigger sequence, you would have to do it like that
[12:46] <t1mp> zsombi: so if the abstract has an action, but you do not want that action triggered when you click the button?
[12:46] <t1mp> weird use case ;)
[12:46] <zsombi> t1mp: or you want to delay the action triggering, like we do in ListItem's case
[12:46] <t1mp> s/abstract/abstract button
[12:47] <maggots> i have a proble i uploaded version 0.1 to the app store and now i'm ready for version 0.2 what do i need to change for it to build the new package?
[12:48] <t1mp> zsombi: delay? in which way? time?
[12:48] <t1mp> zsombi: are you talking about old or new list items?
[12:48] <zsombi> t1mp: don't tell me you haven't seen the ListItem code :D
[12:48] <zsombi> t1mp: new ListItems of course
[12:48] <zsombi> t1mp: we must delay the action triggering in teh leading/trailing actions
[12:49] <zsombi> t1mp: they should be triggered once the animation is over, remember?
[12:49] <zsombi> t1mp: if I do not override AbstractButton.trigger(), then the action will be triggered immediately
[12:50] <zsombi> t1mp: and if the action deletes the item, the UI will crash
[12:50] <zsombi> t1mp: because there will be an ongoing animation to snap the ListItem's panel out
[12:51] <t1mp> right
[12:52] <zsombi> t1mp: but you approved this feature of trigger() overriding before, am surprised we are reloading the talks about it now :)
[12:53] <t1mp> I'm not against it, but I did need to refresh my memory
[12:53] <zsombi> t1mp: you scared me :D
[12:59] <t1mp> zsombi: I think now the update to Empty.qml in 1.2 can be reverted
[13:00] <zsombi> t1mp: I thought I did...
[13:00] <t1mp> zsombi: so when you register a component from cpp, it automatically overrides the qml version?
[13:00] <zsombi> t1mp: yes
[13:00] <t1mp> cool. That may become even more useful in the future :)
[13:01] <zsombi> t1mp: the qmldir is there just to automate the call of qmlRegisterType() fo ryou
[13:01] <t1mp> zsombi: https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/cppAbstractButton/+merge/268442 l.222
[13:01] <zsombi> t1mp: we can even stop a type from being exported in certain version onwards
[13:02] <zsombi> t1mp: yes, I saw it, I'll push an update as long as you confirm nothing else needs to be fixed on the branch
[13:02] <t1mp> zsombi: yes it is good. Should we wait for kalikiana too?
[13:03] <zsombi> t1mp: I dunno... we basically discussed this thing I just implemented there
[13:03] <t1mp> ok
[13:04] <kalikiana> last I checked there's still some 1.2 stuff that's unecessary, in the list item and some import changes
[13:04] <kalikiana> by the looks of it that will be fixed?
[13:04] <zsombi> kalikiana: which ones are?
[13:05] <kalikiana> zsombi: CheckBox, ComboButton, TextField
[13:05] <zsombi> kalikiana: for 1.2 Checkbox and ComboButton we need thiose imports, I am getting ambiguous errors otherwise
[13:05] <zsombi> same for text field
[13:05] <kalikiana> zsombi: oh. why? if they're using the same QML as before..
[13:05] <zsombi> kalikiana: perhaps the different type import for 1.3 messes it up... lemme check again
[13:06] <kalikiana> zsombi: hmm I guess if QML is being funny is fine - I'd just try to avoid unnecessary changes in 1.2 if possible
[13:06] <zsombi> kalikiana: sure, +1 on that, let me check again
[13:07] <kalikiana> thanks
[13:07] <zsombi> kalikiana: the nice thing is that qmlapicheck does the job for me now ;)
[13:07] <zsombi> kalikiana: seems to be fine without 1.2 imports
[13:07] <kalikiana> :-D
[13:08] <zsombi> kalikiana: I guess I had them dues to full cpp button... :)
[13:10] <zsombi> kalikiana: t1mp: pushed an update, rolling back 1.2 changes
[13:20] <zsombi> t1mp: kalikiana: so, should ActionContext.active work same way as the Item.enabled does?
[13:22] <kalikiana> zsombi: in what sense?
[13:23] <kalikiana> are you talking about making it dependent on parents?
[13:23] <zsombi> kalikiana: in a sense that if the parent ActionContext is deactivated, all its child ActionContexts shousl also be deactivated
[13:23] <kalikiana> aha
[13:23] <kalikiana> yeah
[13:23] <kalikiana> we need that behavior
[13:23] <zsombi> kalikiana: state being reflected thru teh action property
[13:24] <zsombi> kalikiana: it gets deactivated, it's just not reported thru teh actuve property
[13:24] <kalikiana> zsombi: yeah
[13:25] <zsombi> kalikiana: so the actions added to these child ActionContexts won't get triggered in these cases, but the active property will still say true
[13:25] <zsombi> kalikiana: I thought so... so, I think then we have a problem of that being override :)
[13:25] <zsombi> kalikiana: same way as the enabled or visible
[13:26] <zsombi> damn it, I have 2sec lag time in chat!!!
[13:27] <zsombi> kalikiana: so, the thing is, when an Item's enabled has a binding, and its parent gets disabled, the enabled will change, but the binding won't get broken
[13:27] <zsombi> kalikiana: which means that if the binding is reevaluated, the enabled will be set back
[13:27] <zsombi> kalikiana: same with visible
[13:27] <kalikiana> zsombi: well, from my point of view we don't really need the magical properties here. if you need to know if a context blocks an action you can ask the context about that
[13:28] <zsombi> kalikiana: sure, internally we do actually
[13:28] <zsombi> kalikiana: its just shoudl we reflect this tru the active property or not... that's the only question
[13:30] <kalikiana> zsombi: we need to ensure trigger() respects its context - there's no requirement beyond that. even a custom component wouldn't care so long as it simply calls that function
[13:31] <kalikiana> the only other aspect would be hotkey registration which probably should depend on whether the context is active
[13:31] <kalikiana> ie. if you have a shortcut ^X in two contexts one of which is enabled, it shouldn't clash
[13:32] <zsombi> kalikiana: I think the shortcut registration can proceed no matter of what, the shortcut matcher otoh takes into account whether the action is activable or not, if not, then won't return the match
[13:32] <zsombi> kalikiana: so in this sense if we have two actions with the same shortcut, and one is activable other si not, only teh activable will be selected
[13:33] <kalikiana> zsombi: yep, if that respects the context state that's all we need
[13:33] <kalikiana> and then there's no need for the action itself to magically change property values
[13:35] <zsombi> kalikiana: right, what I'm trying to sort out with you si the ActionContext.active state :)
[13:36] <zsombi> kalikiana: so if we want that to follow the same setup as Item.enabled/visible, then we may run into the same problemas Item.enabled/visible does
[13:36] <kalikiana> zsombi: oh, you mean having the context change its property value
[13:36] <kalikiana> I was thinking only of the action above
[13:36] <zsombi> kalikiana: actually I was only talking about the context :)
[13:37] <zsombi> kalikiana: like if you change the enabled/visible of a parent item, that affects the child items' properties as well
[13:37] <kalikiana> zsombi: right. my stance is the same, though. I don't find the semantics of those magical properties very nice to work with
[13:37] <zsombi> kalikiana: now, if the child items do have bindings on these, those change these back eventually
[13:37] <kalikiana> it breaks bindings and makes it difficult to know what the real value is
[13:38] <zsombi> kalikiana: the thing is that the enabled is handled behind teh scenes and bindings stay!
[13:39] <kalikiana> zsombi: well, yes, but you still get different values than you should, and you can't know the real state anymore
[13:40] <kalikiana> zsombi: I would like it if there was a way to actually know both
[13:40] <kalikiana> zsombi: it's also very specialized - rotation doesn't work in this way
[13:41] <kalikiana> you change the value, things move around, and the value is the same
[13:41] <zsombi> kalikiana: let me get to a meeting, and we get back to it
[13:41] <kalikiana> k
[13:48] <zsombi> kalikiana: we could have active, and effectiveActive props, what do you think? effectiveActive would be RO, so no binding on it would be doable
[13:49] <zsombi> kalikiana: active would mean the local active, would not collide with the parent actives at all, and wouldn't be driven by that either
[13:54] <kalikiana> zsombi: the question is, what's the use case for it?
[14:26] <davmor2> popey: I found out why some of the apps from the ppa weren't opening.  They rely on Ubuntu.component 1.3 which is wily, that would explain why it worked for you and not me too I guess right?
[14:27] <davmor2> popey: I upgraded today and they all open now :)  Calendar refuses to accept my Google account which makes it a bit meh :(
[14:47] <DS-McGuire> Announcing Ubuntu Themed Days - Looking for feedback: https://www.reddit.com/r/UbuntuAppDev/comments/3ic48m/announcing_ubuntu_themed_days_looking_for_feedback/
[14:58] <zsombi> kalikiana: back now....
[14:58] <zsombi> t1mp: kalikiana: we are going to have a real palette FINALLY!!!
[14:59] <popey> davmor2: yes, I'm on wily
[15:00] <kalikiana> zsombi: my last question wrt ActionContext was, what use case are we looking at for effectiveActive? if we only sort it out internally we don't necessarily want API
[15:00] <zsombi> kalikiana: so, the only use case for effectiveActive I see is testing, however that one can be handled thru triggering actions and not getting any trigger count on the signal sspy
[15:01] <zsombi> kalikiana: right, so I'd then skip it for now until further notice
[15:01] <kalikiana> yeah. I'd expect tests to only test the expected value anyway - there's no need for conditions
[15:01] <zsombi> kalikiana: yes, I do the testing like that now
[15:02] <zsombi> kalikiana: one more thing, I turned ActionContext into Item, the property lookup was really slow... so now those who want to group actions can use the ActionContext, and it is also a focus scope to propagate focusing
[15:04] <zsombi> t1mp: kalikiana: we got 4 color sets, normal, selected, hovered and disabled, and few more palette value names: positive, negative, active, position
[15:04] <zsombi> t1mp: kalikiana: and finally we are going to use these values in the UI spec!!!!!!!!!!!
[15:05] <kalikiana> zsombi: erm, what about focussed?
[15:06] <zsombi> kalikiana: that will be potentially a simple color apart from the palette, as it only happens on components which are focused
[15:07] <zsombi> kalikiana: so the visual component doing the focusing will need to be subtyped in themes if they need different color
[15:07] <zsombi> kalikiana: or, we put it as color in the Palette, without being included in any color value set, I think this would be much better
[15:08] <zsombi> kalikiana: in this way the Palette will have normal, selected, hovered, disabled value sets and focus + focusText pair
[15:11] <zsombi> kalikiana: however we may not even need focusText for now...
[15:11] <kalikiana> zsombi: how is focus different to say selected? you select text and the component assumes focus styling, with the text changing colors
[15:11] <kalikiana> that seems reverse to what you're saying
[15:11] <zsombi> kalikiana: the focus frame will be shown around a text input, and then the selected text will be colored differently, just like now
[15:13] <kalikiana> zsombi: yes. but that means selected isn't a state at all, but focus is
[15:13] <zsombi> kalikiana: hmm.... actually you're right! the selected is actually the focus...
[15:14] <zsombi> kalikiana: or... hold on, no
[15:14] <zsombi> kalikiana: there will be a state in some components, called selected
[15:14] <zsombi> kalikiana: we're gonna use the color set on those components, the focus is focus + normal
[15:15]  * zsombi double checks
[15:16] <kalikiana> zsombi: I'm kind of wondering how these categories are defined. for example normal=enabled/sleeping disabled=!enabled hovered=mouse within the component.... so why isn't focus=activeFocus in the same league as those other folks?
[15:18] <didrocks> jdstrand: hey, I was wondering if the user denied some permissions, like the location one for an app. Is there an easy way for the app itself to know about it? (like showing two label, one "no location available" if no GPS is available and another "location is denied for this application")?
[15:19] <jdstrand> hi
[15:19] <ogra_> didrocks, i guess thats a tvoss question, that stuff should be handled by the trust-store
[15:19] <didrocks> ah, I'm happy to relay :)
[15:19] <jdstrand> there is not a way for the app to specifically ask if it has permission that I know of. it depends on what APIs the service in question offers
[15:20] <didrocks> jdstrand: yeah, for location is just seem that no signal will be sent for instance, but that can also mean we didn't get any GPS fix
[15:20] <jdstrand> eg, does location service provide an api for the app to see if it has access. (I don't think it does)
[15:20] <didrocks> yep, that's exactly it
[15:21] <didrocks> thanks ogra_, jdstrand!
[15:21] <jdstrand> np
[15:32] <aquarius> jdstrand, ping about manual review of apps :)
[15:58] <zsombi> kalikiana: you mean the colors?
[15:58] <zsombi> mzanetti: ping
[16:00] <zsombi> kalikiana: t1mpso, I can happrove https://code.launchpad.net/~zsombi/ubuntu-ui-toolkit/cppAbstractButton/+merge/268442?
[16:00] <zsombi> t1mp: ^
[16:01] <kalikiana> zsombi: yes, as far as I
[16:01] <kalikiana> 'm concerned
[16:01] <zsombi> kalikiana: thx
[16:01] <zsombi> kalikiana: t1mp was waiting on your approval
[16:01] <kalikiana> oh. but I already approved on lp
[16:02] <kalikiana> sorry about that
[16:02] <zsombi> kalikiana: np, I happroved it now, thx + t1mp
[16:02] <zsombi> kalikiana: so, back to colors...
[16:02] <kalikiana> zsombi: yes wrt the colors. it's unclear to me how selected warrants a category in the palette, but focus doesn't
[16:03] <zsombi> kalikiana: so, selected == focus
[16:03] <kalikiana> hmm
[16:03] <zsombi> kalikiana: and we may get an outline + text color pair there to handle the focus coloring of the components
[16:03] <kalikiana> zsombi: well, there's possibly two things we call selected, so we should try to avoid ambiguity here
[16:04] <kalikiana> you can select text - different colors
[16:04] <kalikiana> you can select list items
[16:04] <zsombi> kalikiana: the text selection is called position...
[16:04] <kalikiana> you can select, as in focus
[16:04] <zsombi> kalikiana: the list item selection is made thru checkboxes
[16:04] <kalikiana> zsombi: position?
[16:05] <zsombi> kalikiana: perhaps a bit different, I do n't remember by heart, but we can ammend that
[16:06] <kalikiana> zsombi: I get the feeling if we're not careful the only way to talk about the palette will be with a cheatsheet that shows what the terms mean..
[16:06] <zsombi> kalikiana: then we will have different selections in different components as well, so..
[16:07] <zsombi> kalikiana: I second to that :) it's just we cannot really change the palette value set names like that...
[16:07] <kalikiana> selection styling depends on the component, just like focus does, that is fine
[16:08] <kalikiana> the question is if there is a color that'll be shared - or will selection in that way always be based on other things
[16:08] <zsombi> kalikiana: yes, the text selection will also be used in file manager's selection too... potentially...
[16:08] <zsombi> I mean colors
[16:09] <zsombi> kalikiana: which is why the "position" was added
[16:09] <zsombi> kalikiana: it's just badly named
[16:09] <zsombi> kalikiana: sees UX doc end
[16:10] <kalikiana> zsombi: thing is nobody would ever say "I postioned a few files, now how do I copy them" ;-)
[16:10] <zsombi> kalikiana: LOL exactly... and they really call it as
[16:11] <kalikiana> zsombi: so if "position" means selection in plan english, what does "selection" translate to?
[16:12] <zsombi> kalikiana: just commented on it :D
[16:13] <zsombi> kalikiana: + the "active" seems to be the color they use in focus highlighting...
[16:14] <kalikiana> ah found it in the doc now
[16:14] <kalikiana> okay, so position is even described as selection...
[16:16] <zsombi> right :D
[16:25] <mzanetti> zsombi, pong
[16:25] <zsombi> mzanetti: remember the mouse/keyboard detection thingie?
[16:26] <zsombi> mzanetti: or you had sthing comitted upstream which would do some enumeration for these, right?
[16:29] <zsombi> kalikiana: one more question, do you prefer overlay action context or modal action context naming?
[16:31] <zsombi> kalikiana: maybe we don't even want to exose this...
[16:31] <zsombi> kalikiana: but drive it from the Dialog in some way...
[16:32] <zsombi> mzanetti: do you know what I'm talking about?
[16:38] <mzanetti> zsombi, yes
[16:38] <zsombi> mzanetti: aaaaand? :)
[19:14] <davmor2> popey: coreapps ppa will all the apps get rebuilt for wily?
[19:25] <popey> davmor2: possibly
[21:51] <aquarius> Hm. How do I use i18n.tr to indicate a translation on an HTML string? I have, for example, the string "Hello, this is the <b>world</b>"; how do I express that in an i18n.tr-able form so that it can be translated? I don't want to do i18n.tr("Hello, you are the") + "<b>" + i18n.tr("world") + "</b>" because then someone translating won't get the whole sentence in one go (and so won't know which gender to put the
[21:51] <aquarius>  "the" in)
[21:57] <ahayzen> aquarius, you could put a // TRANSLATORS: comment on the line before which then shows in LP, like we do in the music-app here http://bazaar.launchpad.net/~music-app-dev/music-app/refactor/view/head:/app/components/Helpers/UserMetricsHelper.qml#L30 this then appears like this https://translations.launchpad.net/music-app/refactor/+pots/com.ubuntu.music/en_GB/25/+translate
[21:57] <aquarius> ahayzen, I could, but then the comment would have to say "be careful to keep all the HTML formatting in place or you'll break everything" :-)
[21:58] <aquarius> which I don't really wanna do
[21:58] <ahayzen> :-)
[22:00] <aquarius> what I *want* to do is this: i18n.tr("Hello, your port is number %1".replace("%1", "<b>%1</b>")).arg(port);
[22:01] <aquarius> but I bet that doesn't work right because it's not a plain string inside the i18n.tr call so the thing which parses the QML file won't get it correctly.
[22:03] <aquarius> and I can't replace it *afterwards* (that is, i18n.tr("Port is %1 or maybe %2").arg(port1,port2).replace(port1, "<b>"+port1+"</b>").replace(port2, "<b>"+port2+"</b>") because port1 might be a substring of port2
[22:06] <ahayzen> oo that looks like the tag() thing we never got working https://developer.ubuntu.com/api/apps/qml/sdk-15.04/Ubuntu.Components.i18n/#tag-method
[22:11] <aquarius> ya, I was right, I can't do clever things inside an i18n.tr call.
[22:17] <aquarius> actually... maybe I can.
[22:19] <aquarius> ha haaaa!
[22:20] <aquarius> no, wait.
[22:21] <aquarius> darn it.
[22:21] <aquarius> my trick won't work.
[22:24] <mcphail> aquarius: you can have a function as the 2nd argument to String.replace, so you don't have to rely on the dumb defaults to do the replacement (and hence getting mixed up with substrings)
[22:24] <aquarius> mcphail, the problem is that I don't know what to replace.
[22:25] <aquarius> I would like the output string to be: <p>Hello, your number is 31</p>. I have a variable, n, which is set to 31. What should my i18n.tr line be?
[22:26]  * mcphail looks up his javascript book
[22:26] <aquarius> Clearly the string that goes to translators should be "Hello, your number is 31" (with no HTML in it).
[22:28] <aquarius> (er, sorry, the output string should be <p>Hello, your number is <b>31</b></p>
[22:29] <aquarius> i18n.tr("Hello, your number is %1").arg(n).replace("%1", "<b>%1</b>") doesn't work because there's no %1 in the string by the time the replace runs
[22:30] <aquarius> i18n.tr("Hello, your number is %1").replace("%1", "<b>%1</b>").arg(n) doesn't work because replace doesn't return a magic thing with a .arg method, it just returns a string
[22:30] <aquarius> i18n.tr("Hello, your number is %1".replace("%1", "<b>%1</b>")).arg(n) doesn't work because it won't find a match to translate
[22:30] <mcphail> aquarius: what about i18n.tr("Port is do_not_translate_this_placeholder_1 or maybe do_not_translate_this_placeholder_2").replace(/do_not_translate_this_placeholder_1/, "<b>"+n1+"</b>").replace(/...etcetc
[22:31] <mcphail> ugly but might work
[22:31] <aquarius> then I'm doing the substitutions myself rather than i18n.tr doing them
[22:31] <aquarius> I suppose since it's just a port number, I could do that
[22:32] <mcphail> aquarius: can't see how a port number would be internationalised. Different if it was something with a decimal point or whatever
[22:32] <aquarius> ya
[22:32] <aquarius> so, "your port is $PORT$" with a translator comment of "do not translate the $PORT$, just put it where the port number would be"
[22:33] <mcphail> Might well work
[22:34] <mcphail> aquarius: I'm sure the GNU gettext manual has a section on best practice for this kind of thing...
[22:41] <mcphail> aquarius: "HTML markup, however, is common enough that it’s probably ok to use in translatable strings.", according to GNU anyway
[22:41] <aquarius> right. I don't believe that :)
[22:42] <aquarius> I do not want translators to have to understand markup
[22:42] <mcphail> aquarius: fair enough, but at least you can quote a source which says it is OK :) http://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html#Preparing-Strings
[22:42] <aquarius> especially since if they, for example, translate <p><font size="7">Hello</font></p> to <p><font size="7>Bonjour</font></p> by accident then it will completely break the app