#amara

sylvainc, - in gh-1379 - it seems we've lost the marking of versions as either private or publich

public

sylvainc, 5f154277c791

oops

yes, thanks for catching that, it should not display private versions, right?

it would be better to not display things that users can't see or select anyway

ok, good, and also I guess the "Private" word was translated depending on the locale, and my change would have removed that. The bug was actually just that "Private" or "Public" was tranlsatted, so if locale is not English, it was not considered "Public"

i see

question -

what about same-language visibility

so if I'm working on a language and all my previous versions are drafts - should I be able to see them in the reference side ?

right now we can't

so if that's complex - it's ok to just leave it -

but do you think a person would want to see previous revisions?

I can check, right now I think it is only based on the visible property, not on whether it is a draft

sorry - that's my wording

basically - I mean a private version of the current working language

oh, ok, that simplifies

I guess if we mark them as private, we should really necer display them

never i mean

but...

on a tasks team, everything is private until it gets approved.

then the approved version get set to public

so while it's going through that review / approve process there could be many private drafts.

but ...

Maybe I pay too much attention to the name we gave it, private does not mean "secret", right, more like "unapproved"

let's just skip it for now

yeah - or like draft

in which case we could maybe display it if all versions are private, but maybe in a way that users know it is special

I think it only matters for the working language

Probably worth thinking more about it, I suggest to first fix that current bug, then think of how to improve it

ok

worksforme

ok, cool

user's never have had that visibility before, and if they really needed it - they could look something up on the revisions page

maybe we'll get fancier when we do the collab model but not mess around with tasks related stuff

Do you think we need two distincts status: private/public and draft/approved

no

I'd prefer to either not even show anything that's private

ok

or just mark the private ones as such

but I'd prefer to not show them - as it just makes the list full of stuff people can't see

ok,

would there be a use case where the original language subtitles is done, but not approved, and you'd like translators to be able to start translating anyway

so sylvainc

pretty sure TED doesn't want users to access unapproved subs

ok sylvainc I see we are back to the way we were - that's good

ok, good!

janeted: hey, got a few reports from our On Demand team, where approving a tasks doesn't marking the subtitle complete. Sending an email w/ more details

Don't bother bendk has already fixed it

just 1 more issue with the changes and it should be done

DarrenBridenbeck, ^^

I think I fixed that issue as well janeted

ok- checking now

janeted: hahaha! Thanks @bendk

janeted: bendk hi-5's to you both!

no - it just means that the TED team is faster at finding bugs

sylvainc, can you check this pull request, please: https://github.com/pculture/unisubs/pull/1384

yes, saw it

bendk, it looks like we never did this pr: https://github.com/pculture/unisubs/pull/1364 can you check it?

looks fine with me

it can't be automatically merged though

probably someone just needs to remake the compiled CSS file

ok

i can do that

and this sylvainc I think is ready

and that's a good batch of stuff!

good. 1363 should now merge fine, and 1384 was merged

ok, so we have 1384, 1383 and 1364 merged

ehazlett, - you around?

janeted: yep

can you please do another sync of translations and deploy staging?

yep -- just synced and was ready to push to production

oh sweet

have more come in in the last 20 min?

no then

ok -- all i have to do is deploy prod

but there's a few tickets that we would be able to deploy shortly

so if I can do a quick check on staging, can get them all together

also if we can do this pr: https://github.com/pculture/unilangs/pull/14

we could use a unilangs update too

cool

i'll do that -- i'll need to rebuild the image

perfect, thanks

yw

ehazlett, will that staging deploy be done soon?

janeted: you around?

Hi yes

so I'm working on 1376, the translation ticket

bendk, what's up?

and I'm wondering how much is translated

maybe I shouldn't be replacing some of these strings that already have translations

the basic idea is to make all the strings have the same syntax

so "New message on Amara: {{ subject }}"

Instead of: "New message on Amara: %(subject)s"

Another option would be to use the %(name)s syntax, but that means we will always have at least 2 different styles, since django uses "{{ name }}"

here's the transifex link - it varies. https://www.transifex.com/projects/p/universals...

So we'd potentially lost some translations while they get updated, but would reduce the amount of potential translation errors leading to bugs

okay, I'll go for it

it's also going to require a bunch of testing, since basically every string is going to be changed

that pt-br bug was pretty bad I thought

oh god. ok

agreed

well, not every string

but many strings, and only a few have unittests that call them

selenium tests use some too, I think

I doubt I will mess up the conversion, but it's so many strings

yeah, so maybe just running the selenium tests should cover it

okay, gotta go

ok

hopefully that will be done soon

k

also I'm pretty far into the magic-autopause feature

if we can get some styles for that it would be great

ah - can we just do a simple pulldown, similar to how you have the language pulldown?

I think it would fit up on the keyboard shortcuts panel on the right side, what do you think?

bendk, - I mean the language pulldown in the dialog

where it looks flat, but is a pulldown menu that, -- select language --

and maybe we'd need some help to explain how it works