Opened on 06/20/2017 at 09:13:51 PM
Last modified on 09/17/2019 at 12:27:03 PM
#5340 new change
Automate fix tags
| Reported by: | juliandoucette | Assignee: | |
|---|---|---|---|
| Priority: | P3 | Milestone: | Websites editing service |
| Module: | Sitescripts | Keywords: | |
| Cc: | wspee, kvas, jsonesen, ire, saroyanm, lisabielik | Blocked By: | |
| Blocking: | Platform: | Unknown / Cross platform | |
| Ready: | yes | Confidential: | no |
| Tester: | Unknown | Verified working: | no |
| Review URL(s): | |||
Description (last modified by kvas)
Background
Until recently, we have tried to <fix> all names, numbers inside translatable strings consistently across websites. This was intended to help translators identify words that they probably should not translate in crowdin.
Problem is, this creates more work for us (developers) because we have to read all website content and add <fix> tags manually. This also creates more work for our translation manager because [her translators do not currently use crowdin or understand <fix> tags, she does not currently dedicate resources to reviewing translations from our community].
What to change
I would like to change our policy to not inserting <fix> tags manually - and relying on the CMS to insert them automatically around all [numbers, whitelisted expressions] inside translation strings - by passing an option (which is disabled by default - because fix tags are not currently benefiting our translation manager) to our translation procedure.
Implementation note:
- The relevant code for working with translation strings exists in cms/bin/translate.py.
- The functionality should be an option to translate.py (or a separate script if it turns out to be useful to run it without the rest of translate.py functionality).
Attachments (0)
Change History (8)
comment:1 follow-up: ↓ 2 Changed on 06/20/2017 at 09:17:17 PM by juliandoucette
- Description modified (diff)
- By "whitelisted expressions" I mean basic strings and regular expressions
- I'm also suggesting that we could create a shared whitelist of expressions that works for all of our websites
comment:2 in reply to: ↑ 1 Changed on 06/21/2017 at 09:25:42 AM by kvas
Replying to juliandoucette:
- I'm also suggesting that we could create a shared whitelist of expressions that works for all of our websites
Yeah, I guess we could have a global config (in something like ~/.cms) and a local one in the website repository if something needs to be added or overridden. The global config could be shared and synchronized via codetools repository.
comment:3 Changed on 06/21/2017 at 11:16:17 AM by juliandoucette
Yeah, I guess we could have a global config (in something like ~/.cms) and a local one in the website repository if something needs to be added or overridden. The global config could be shared and synchronized via codetools repository.
No objections.
If you could confirm that you think this is possible and a good idea then we could change our policy immediately and save a lot of time.
comment:4 Changed on 06/21/2017 at 04:01:25 PM by kvas
I think this is possible and a good idea.
comment:5 Changed on 06/21/2017 at 04:35:45 PM by kvas
- Description modified (diff)
- Priority changed from Unknown to P3
- Ready set
comment:6 Changed on 07/13/2017 at 08:32:55 AM by ire
- Cc ire added; iaderinokun removed
comment:7 Changed on 09/05/2017 at 12:16:30 PM by juliandoucette
- Milestone set to Websites editing service
comment:8 Changed on 09/17/2019 at 12:27:03 PM by kvas
Dear stakeholders of this ticket,
I'm cleaning up Sitescripts tickets in Trac due to its phase out. This is one of the tickets that I could not myself close or move, so I need your input on it.
Please let me know if this ticket is still relevant for you and we can then discuss where it should be moved. If you think that this ticket is no longer relevant, you can write a comment explaining this or just ignore this message.
If I see now comments in the ticket on October 14, I will close it as rejected.
Best regards,
Vasily
