Based on the discussions we've had in IRC, the way I'd like to see this go:
1. Have three languages: en is the parent of en_dw which in turn is the parent of en_dw_live (or whatever). 2. Site copy people work entirely in en_dw_live and entirely through /translate onsite. 3. Devs work entirely in either en_dw (non-free stuff like tropo) or en (everything else). 4. At some point, stuff in en_dw_live can be pushed up to en/en_dw so that the default text for a clean install doesn't suck. 5. If devs need to change something so that the live text on the site changes, I am told they can set staleness to make the en or en_dw version show up over the en_dw_live version, and that copy people can then update/modify as necessary. I'll confess I didn't fully understand that part, but that's what I was led to believe.
Main problem I see with this is the following scenario: - en text says "You can't have sparkly ponies" - en_DW text says "You can't have sparkly ponies, unless you have a Very 'Spensive Account" (because sparkly ponies are dw-nonfree) - en_DW_live text says "You can't have sparkly ponies, unless you haver a <a href="http://www.dreamwidth.org/support/faqbrowse.bml?faqid=23">Very 'Spensive Account</a>" (with the FAQ telling something about Very 'Spensive Accounts)
When we try to push this back to the repo, it's hard to tell automatically whether the change should be pushed to en_DW or en. (The standard case where the text only exists in en or in en_DW is easy - just push it back there.)
However, that sounds like a minor problem, and one that we can tackle later.
Mainly, that IMO there shouldn't be an en_DW_live.dat, or at least only as a staging area. Strings in that language in the DB should eventually be merged into either en.dat or en_DW.dat in the source repos. When the string exists in only one, thjat's easy. But when (as in this example) it's present in both, it needs some way (possibly manual input) to decide whether the string should go to en.dat, en_DW.dat, both, or neither.
![[staff profile]](https://www.dreamwidth.org/img/silk/identity/user_staff.png){kind=small}
![[site community profile]](https://www.dreamwidth.org/img/comm_staff.png){kind=small}
no subject
1. Have three languages: en is the parent of en_dw which in turn is the parent of en_dw_live (or whatever).
2. Site copy people work entirely in en_dw_live and entirely through /translate onsite.
3. Devs work entirely in either en_dw (non-free stuff like tropo) or en (everything else).
4. At some point, stuff in en_dw_live can be pushed up to en/en_dw so that the default text for a clean install doesn't suck.
5. If devs need to change something so that the live text on the site changes, I am told they can set staleness to make the en or en_dw version show up over the en_dw_live version, and that copy people can then update/modify as necessary. I'll confess I didn't fully understand that part, but that's what I was led to believe.
no subject
- en text says "You can't have sparkly ponies"
- en_DW text says "You can't have sparkly ponies, unless you have a Very 'Spensive Account" (because sparkly ponies are dw-nonfree)
- en_DW_live text says "You can't have sparkly ponies, unless you haver a <a href="http://www.dreamwidth.org/support/faqbrowse.bml?faqid=23">Very 'Spensive Account</a>" (with the FAQ telling something about Very 'Spensive Accounts)
When we try to push this back to the repo, it's hard to tell automatically whether the change should be pushed to en_DW or en. (The standard case where the text only exists in en or in en_DW is easy - just push it back there.)
However, that sounds like a minor problem, and one that we can tackle later.
no subject
Do you see any problem with that?
no subject