Issue 29422615: Issue 5068 - Define translation string format (Closed)
|
Created:
April 26, 2017, 11:11 a.m. by juliandoucette Modified:
Oct. 26, 2017, 3:07 p.m. CC:
tamara, Jon Sonesen, Thomas Greiner Visibility:
Public. |
Patch Set 1 : First draft #
Total comments: 43
Patch Set 2 : Proposed changes #Patch Set 3 : Added UID vs OID detail #Patch Set 4 : Simplified proposed changes #MessagesTotal messages: 16
On 2017/04/26 11:11:34, juliandoucette wrote: Done first draft. It's high time we documented this somewhere. I believe we are still divided on the following topics: - Is it worth it for our us and/or our contributors? vs Is it worth it for us? - to use <fix> tags - The exact format of string identifiers - The exact format and *when it's necessary* to use string context I have put my current opinion/understanding into this document based on our previous discussions. Can you please give me a hand managing/resolving these issues Winsley?
Added a few notes. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... File translation-string-format.md (right): https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:25: : An identifier context should describe context in which the string appears in HTML. e.g. {h: heading, p: paragraph, li: list item} Note: We have had a policy about spelling things out e.g. "paragraph" instead of "p". I'm not sure if we can/should break this rule. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:28: : A number should uniquely identify an identifier among other similar identifiers. e.g. among multiple consecutive list items or paragraphs with the same identifier summary and context. Note: A number is not necessary if there are not more than one of the same identifier.
Thanks for starting this Julian. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... File translation-string-format.md (right): https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:1: # Translation string format I think it makes sense to define if this document applies to Website or to the UI module as well... We can define that this applies to the Website and extend for UI and or update to it if it will make sense.. Anyway for the stringID decisins for UI module we will need Thomas as well. I'll review this considering practices we used/started to use across websites module. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:5: ## Brackets Suggestion: I think "required" can go right next to heading. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:7: Two curly braces must (required) go at the beginning and end of a translated string in Markdown and HTML format. Suggestion: I think from "must" it's obvious that it's required. We can omit "(required)" https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:13: - An identifier may identify only one string on one page Word "may" sound "balanced" for me, let me know if I'm wrong.. I think this should be more strong, like "should". https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:15: - An identifier may contain only lowercase latin letters and dashes Suggestion: We can make this more strong. "should" instead of "may". Note: each time we use may it will require content creator to think twice what to use. In case of previous point I can see why you are using "balanced" word though. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:22: : An identifier summary should describe the contents of the string or it’s parent heading in as few words as possible. Note: and example here I think could make things bit more clear, but I think we can revisit the example and find wording that will make this point more describing later on.. Separate review. let's first finalize this version. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:25: : An identifier context should describe context in which the string appears in HTML. e.g. {h: heading, p: paragraph, li: list item} On 2017/05/18 08:54:37, juliandoucette wrote: > Note: We have had a policy about spelling things out e.g. "paragraph" instead of > "p". I'm not sure if we can/should break this rule. I think if we agree with this approach this can be an exception, because here you are using the HTML element intentionally to make it easy searchable, rather than shortening to save space. Though it will require changing the string name if you will change the HTML element, which might lead to lose of the translation, for example if we start generating them on the fly.. So here are two extremes: * Think meaningful stringID to reflect the meaning of the string Cons: Hard to autogenerate Pros: Not required to update stringID if Semantic changes. * Use HTML reference, to make it autogeneratable Cons: We might loose the translations if the HTML element is changed Pros: We can auto-generate, improve the speed. Me personally don't have strong opinion about which to choose though I lean towards later one (I see that both solution are not ideal), but we still need to keep that in mind and ideally find solution, because I imagine this can become tricky issue, if the layout or semantics changes. If you have anything on your mind between this both extremes let me know. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:28: : A number should uniquely identify an identifier among other similar identifiers. e.g. among multiple consecutive list items or paragraphs with the same identifier summary and context. Having number "required" will minimize the effort of automation. If this is the final goal. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:30: ## Context Suggestion: Let's mark optional here rather than in the description, if you want to emphasis that context in general is optional for people who will read this rather than the "Readme" of the CMS. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:44: - A string’s content should (optionally) be separated from it’s closing braces by one space Doesn't it mean that space should also being applied in between opening braces and Identifier. I mean "{{ stringId[context] string }}" rather than "{{stringId[context] string }}" ?
Thanks Manvel :) @Ire, @Lisa, @Winsley your feedback is welcome here too. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... File translation-string-format.md (right): https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:1: # Translation string format On 2017/06/01 12:07:25, saroyanm wrote: > I think it makes sense to define if this document applies to Website or to the > UI module as well... > > We can define that this applies to the Website and extend for UI and or update > to it if it will make sense.. > > Anyway for the stringID decisins for UI module we will need Thomas as well. > > I'll review this considering practices we used/started to use across websites > module. Acknowledged. I don't know how translations are done in the extension. Do strings have the same parts? https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:5: ## Brackets On 2017/06/01 12:07:25, saroyanm wrote: > Suggestion: I think "required" can go right next to heading. Acknowledged. Good point. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:7: Two curly braces must (required) go at the beginning and end of a translated string in Markdown and HTML format. On 2017/06/01 12:07:26, saroyanm wrote: > Suggestion: I think from "must" it's obvious that it's required. > We can omit "(required)" Acknowledged. I guess I thought this made it more formal :D - I'll remove unless someone else objects. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:13: - An identifier may identify only one string on one page On 2017/06/01 12:07:26, saroyanm wrote: > Word "may" sound "balanced" for me, let me know if I'm wrong.. I think this > should be more strong, like "should". "may" means *can*. "should" means *preferably*. "should" is not right because an identifier can **only** (not *preferably*) identify one string on one page. That being said, perhaps "can" is more direct and less *balanced* than "may"? I don't have a strong opinion. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:15: - An identifier may contain only lowercase latin letters and dashes On 2017/06/01 12:07:26, saroyanm wrote: > Suggestion: We can make this more strong. "should" instead of "may". > Note: each time we use may it will require content creator to think twice what > to use. In case of previous point I can see why you are using "balanced" word > though. See comment above. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:22: : An identifier summary should describe the contents of the string or it’s parent heading in as few words as possible. On 2017/06/01 12:07:26, saroyanm wrote: > Note: and example here I think could make things bit more clear, but I think we > can revisit the example and find wording that will make this point more > describing later on.. Separate review. let's first finalize this version. Acknowledged. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:25: : An identifier context should describe context in which the string appears in HTML. e.g. {h: heading, p: paragraph, li: list item} On 2017/06/01 12:07:25, saroyanm wrote: > On 2017/05/18 08:54:37, juliandoucette wrote: > > Note: We have had a policy about spelling things out e.g. "paragraph" instead > of > > "p". I'm not sure if we can/should break this rule. > > I think if we agree with this approach this can be an exception, because here > you are using the HTML element intentionally to make it easy searchable, rather > than shortening to save space. > > Though it will require changing the string name if you will change the HTML > element, which might lead to lose of the translation, for example if we start > generating them on the fly.. > > So here are two extremes: > * Think meaningful stringID to reflect the meaning of the string > Cons: Hard to autogenerate > Pros: Not required to update stringID if Semantic changes. > * Use HTML reference, to make it autogeneratable > Cons: We might loose the translations if the HTML element is changed > Pros: We can auto-generate, improve the speed. > > Me personally don't have strong opinion about which to choose though I lean > towards later one (I see that both solution are not ideal), but we still need to > keep that in mind and ideally find solution, because I imagine this can become > tricky issue, if the layout or semantics changes. If you have anything on your > mind between this both extremes let me know. Good point. I think there is a middle ground here. I think that text in a heading or on a button may be translated differently than the same text alone in a paragraph. Therefore, I think there is a place for *context* in string IDs. I think the middle ground is less specific than an exact HTML tag and more specific than [heading, paragraph, button-label, list-item]. I will wait for your feedback before digging into this deeper. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:28: : A number should uniquely identify an identifier among other similar identifiers. e.g. among multiple consecutive list items or paragraphs with the same identifier summary and context. On 2017/06/01 12:07:25, saroyanm wrote: > Having number "required" will minimize the effort of automation. If this is the > final goal. I agree. I found it awkward to use and/or not use this number in practice. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:30: ## Context On 2017/06/01 12:07:25, saroyanm wrote: > Suggestion: Let's mark optional here rather than in the description, if you want > to emphasis that context in general is optional for people who will read this > rather than the "Readme" of the CMS. Acknowledged. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:44: - A string’s content should (optionally) be separated from it’s closing braces by one space On 2017/06/01 12:07:26, saroyanm wrote: > Doesn't it mean that space should also being applied in between opening braces > and Identifier. > I mean "{{ stringId[context] string }}" rather than "{{stringId[context] string > }}" ? I didn't know that we could put a space before the stringId until Ire submitted a pull request like this recently :D ... Now that I Think of it, I like the first one.
Added clarification. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... File translation-string-format.md (right): https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:25: : An identifier context should describe context in which the string appears in HTML. e.g. {h: heading, p: paragraph, li: list item} > I think the middle ground is less specific than an exact HTML tag and more > specific than [heading, paragraph, button-label, list-item]. I'm afraid this was unclear. What I mean is that there are probably contexts which are relevant for several types of HTML elements. And that we can probably determine what these contexts are. [heading, body, label, item] may be a good start.
https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... File translation-string-format.md (right): https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:1: # Translation string format It would be really helpful to include some examples in this document. We can have a sample page that shows how the translation strings are used in different contexts, e.g. a heading, paragraph, several list items, etc. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:7: Two curly braces must (required) go at the beginning and end of a translated string in Markdown and HTML format. On 2017/06/07 16:07:39, juliandoucette wrote: > On 2017/06/01 12:07:26, saroyanm wrote: > > Suggestion: I think from "must" it's obvious that it's required. > > We can omit "(required)" > > Acknowledged. > > I guess I thought this made it more formal :D - I'll remove unless someone else > objects. I think, as Manvel suggested later in this doc, that the "required" should go in brackets next to the heading, i.e. `## Brackets (required)`. I think it is useful to have the word required there, even though it says "must", but I agree that having it right after the word "must" seems like a duplicate. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:44: - A string’s content should (optionally) be separated from it’s closing braces by one space On 2017/06/07 16:07:39, juliandoucette wrote: > I didn't know that we could put a space before the stringId until Ire submitted > a pull request like this recently :D ... Now that I Think of it, I like the > first one. I also prefer the first option. But I think we should either have no spaces next to the curly braces, or one space, i.e. "{{ stringId[context] string }}" or "{{stringId[context] string}}". I don't think we should have no-space on one side and a space on the other, i.e. "{{stringId[context] string }}" https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:48: ## Jinja2 format translation strings NIT: It's a bit confusing here to start talking about a different format. I think it should be stated at the beginning of the document that there are 2 formats, and that the document covers the first format earlier. As an extra nitty NIT, the heading levels could be reworked a bit so it's more clear. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:63: ### Common uses Can we have a rule on whether the company name and products should always be surrounded by a <fix>?
Thanks Ire! https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... File translation-string-format.md (right): https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:1: # Translation string format On 2017/06/08 11:18:34, ire wrote: > It would be really helpful to include some examples in this document. We can > have a sample page that shows how the translation strings are used in different > contexts, e.g. a heading, paragraph, several list items, etc. Acknowledged. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:7: Two curly braces must (required) go at the beginning and end of a translated string in Markdown and HTML format. On 2017/06/08 11:18:34, ire wrote: > On 2017/06/07 16:07:39, juliandoucette wrote: > > On 2017/06/01 12:07:26, saroyanm wrote: > > > Suggestion: I think from "must" it's obvious that it's required. > > > We can omit "(required)" > > > > Acknowledged. > > > > I guess I thought this made it more formal :D - I'll remove unless someone > else > > objects. > > I think, as Manvel suggested later in this doc, that the "required" should go in > brackets next to the heading, i.e. `## Brackets (required)`. I think it is > useful to have the word required there, even though it says "must", but I agree > that having it right after the word "must" seems like a duplicate. Acknowledged. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:44: - A string’s content should (optionally) be separated from it’s closing braces by one space On 2017/06/08 11:18:34, ire wrote: > On 2017/06/07 16:07:39, juliandoucette wrote: > > I didn't know that we could put a space before the stringId until Ire > submitted > > a pull request like this recently :D ... Now that I Think of it, I like the > > first one. > > I also prefer the first option. But I think we should either have no spaces next > to the curly braces, or one space, i.e. "{{ stringId[context] string }}" or > "{{stringId[context] string}}". I don't think we should have no-space on one > side and a space on the other, i.e. "{{stringId[context] string }}" > Acknowledged. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:48: ## Jinja2 format translation strings On 2017/06/08 11:18:34, ire wrote: > NIT: It's a bit confusing here to start talking about a different format. I > think it should be stated at the beginning of the document that there are 2 > formats, and that the document covers the first format earlier. As an extra > nitty NIT, the heading levels could be reworked a bit so it's more clear. Acknowledged. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:63: ### Common uses On 2017/06/08 11:18:34, ire wrote: > Can we have a rule on whether the company name and products should always be > surrounded by a <fix>? Acknowledged. I guess "optional" and "common uses" are a little misleading here. Fix tags are *optional* in the sense that the code will work without them. Not *optional* in the sense that the code will pass review without them. There are two cases where they really come in handy: 1. When their contents may change without affecting the rest of the string - e.g. "We have <fix>100</fix> employees" 2. When their contents should **not** change - e.g. "My name should remain <fix>Julian Doucette</fix> in all languages"
You're welcome :) https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... File translation-string-format.md (right): https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:63: ### Common uses On 2017/06/08 21:07:51, juliandoucette wrote: > I guess "optional" and "common uses" are a little misleading here. Fix tags are > *optional* in the sense that the code will work without them. Not *optional* in > the sense that the code will pass review without them. Yes, you're right. I was referring to the latter type of "optional". > There are two cases where they really come in handy: > > 1. When their contents may change without affecting the rest of the string > - e.g. "We have <fix>100</fix> employees" > 2. When their contents should **not** change > - e.g. "My name should remain <fix>Julian Doucette</fix> in all languages" Okay great. I think including examples like this for each of the bullet points would help here. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:67: - names (people, brands, products) Also, is there a rule on whether "eyeo", "Adblock Plus", etc, should be fixed?
Hi all, Thanks for doing this! Just a couple suggestions from my end: 1. I think the more examples we include in this document the better. 2. Perhaps we can create an additional document that contains an actual page of text with all appropriate formatting so that anyone needing to create/edit a file has a visual reference. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... File translation-string-format.md (right): https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:1: # Translation string format On 2017/06/08 11:18:34, ire wrote: > It would be really helpful to include some examples in this document. We can > have a sample page that shows how the translation strings are used in different > contexts, e.g. a heading, paragraph, several list items, etc. Totally agree with Ire. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:22: : An identifier summary should describe the contents of the string or it’s parent heading in as few words as possible. On 2017/06/01 12:07:26, saroyanm wrote: > Note: and example here I think could make things bit more clear, but I think we > can revisit the example and find wording that will make this point more > describing later on.. Separate review. let's first finalize this version. We should include an example. Personally, I'd like us all to use the same format (because I'm anal like that), so we all know what to do and how to do it. Plus, I think it just looks cleaner. Nitpick: 'it's' should be 'its'
Thanks Lisa :) https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... File translation-string-format.md (right): https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:22: : An identifier summary should describe the contents of the string or it’s parent heading in as few words as possible. > Nitpick: 'it's' should be 'its' You just taught me something :)
https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... File translation-string-format.md (right): https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:1: # Translation string format On 2017/06/07 16:07:39, juliandoucette wrote: > On 2017/06/01 12:07:25, saroyanm wrote: > > I think it makes sense to define if this document applies to Website or to the > > UI module as well... > > > > We can define that this applies to the Website and extend for UI and or update > > to it if it will make sense.. > > > > Anyway for the stringID decisins for UI module we will need Thomas as well. > > > > I'll review this considering practices we used/started to use across websites > > module. > > Acknowledged. > > I don't know how translations are done in the extension. Do strings have the > same parts? I think strings are very similar to what we have, it's more in between of "Think meaningful stringID to reflect the meaning of the string" and reflecting location, for examples in the tabs or sections. So they are very close to this one. I don't see an issue adopting this practice in the UI as well. Anyway websites contains way more strings than the UI, so having automation in Websites currently is more crucial rather than in shared UI. Adopting final version completely or partially in ABP shared UI will require @Thomas final go as well. My suggestion: let's meet requirements of websites module and adopt in UI later. I don't want to block current state with additional layer. Suggestion: Add @Thomas as a CC to current review here. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:1: # Translation string format On 2017/06/08 11:18:34, ire wrote: > It would be really helpful to include some examples in this document. We can > have a sample page that shows how the translation strings are used in different > contexts, e.g. a heading, paragraph, several list items, etc. Yes, I also agree with you. Suggestion: I think examples shouldn't block launching the initial version with "hard rules. I suggest adding only examples that are crucial for this version of the document and add more in future to make the document more visual with the examples. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:13: - An identifier may identify only one string on one page On 2017/06/07 16:07:39, juliandoucette wrote: > On 2017/06/01 12:07:26, saroyanm wrote: > > Word "may" sound "balanced" for me, let me know if I'm wrong.. I think this > > should be more strong, like "should". > > "may" means *can*. "should" means *preferably*. "should" is not right because an > identifier can **only** (not *preferably*) identify one string on one page. That > being said, perhaps "can" is more direct and less *balanced* than "may"? I don't > have a strong opinion. In this context I understand wording this way: * May, can - expressing possibility * Should, must - expressing obligation In this case I was suggesting to express obligation, so people will not use same identifier for different strings. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:15: - An identifier may contain only lowercase latin letters and dashes On 2017/06/07 16:07:38, juliandoucette wrote: > On 2017/06/01 12:07:26, saroyanm wrote: > > Suggestion: We can make this more strong. "should" instead of "may". > > Note: each time we use may it will require content creator to think twice what > > to use. In case of previous point I can see why you are using "balanced" word > > though. > > See comment above. same as the comment above. https://codereview.adblockplus.org/29422615/diff/29422620/translation-string-... translation-string-format.md:25: : An identifier context should describe context in which the string appears in HTML. e.g. {h: heading, p: paragraph, li: list item} On 2017/06/07 16:07:39, juliandoucette wrote: > On 2017/06/01 12:07:25, saroyanm wrote: > > On 2017/05/18 08:54:37, juliandoucette wrote: > > > Note: We have had a policy about spelling things out e.g. "paragraph" > instead > > of > > > "p". I'm not sure if we can/should break this rule. > > > > I think if we agree with this approach this can be an exception, because here > > you are using the HTML element intentionally to make it easy searchable, > rather > > than shortening to save space. > > > > Though it will require changing the string name if you will change the HTML > > element, which might lead to lose of the translation, for example if we start > > generating them on the fly.. > > > > So here are two extremes: > > * Think meaningful stringID to reflect the meaning of the string > > Cons: Hard to autogenerate > > Pros: Not required to update stringID if Semantic changes. > > * Use HTML reference, to make it autogeneratable > > Cons: We might loose the translations if the HTML element is changed > > Pros: We can auto-generate, improve the speed. > > > > Me personally don't have strong opinion about which to choose though I lean > > towards later one (I see that both solution are not ideal), but we still need > to > > keep that in mind and ideally find solution, because I imagine this can become > > tricky issue, if the layout or semantics changes. If you have anything on your > > mind between this both extremes let me know. > > Good point. I think there is a middle ground here. I think that text in a > heading or on a button may be translated differently than the same text alone in > a paragraph. Therefore, I think there is a place for *context* in string IDs. I > think the middle ground is less specific than an exact HTML tag and more > specific than [heading, paragraph, button-label, list-item]. > > I will wait for your feedback before digging into this deeper. I agree with you. Would be great to come up with the list of exceptions and best with the examples as well. Having Heading, menu items and Button labels as a start for the exception can be good start I think.
@Vasily, @Jon, @Winsley The use of <fix> tags has been a point of contention in the past. I believe the two sides of this argument can be summarized as follows: 1. Fix tags have two major benefits a. Fix tags can help us update numbers within strings without invalidating translations b. Fix tags can help us prevent translation of names that we don't want translated on crowdin (e.g. brand names, product names, people's names, etc) 2. Our current process relies on a translation manager that a. Does not dispose of the necessary resources/knowledge to approve translations from community members for websites on Crowdin in languages that she doesn't know b. Acquires translations from an agency that does not enter them into crowdin; thus creating more work for her (putting in, taking out, and reviewing fixes) Regardless, I think we all agree that they are a hassle to manage. I think that we can either: a. Stop using fix tags completely b. Automate their insertion - By automatically surrounding numbers in strings with fix tags - By automatically surrounding whitelisted words in strings with fix tags What do you think?
It's hard for me to judge whether <fix> tags are worth the hassle -- I don't use the CMS all that much myself. Perhaps, as it often is, the answer is "it depends". If some content authors and translators would like to not use them, I certainly have no objection. Automatic insertion might be an interesting option that I'd be willing to discuss. If we find a way to define what should become a fixed string that makes the autoinsertion not to hard to implement, perhaps we could do it. Numbers and the words from a whitelist sounds not too hard. Would that be enough? Perhaps we create an issue for this, if this saves a sizable amount of work.
On 2017/06/14 18:07:28, Vasily Kuznetsov wrote: > Perhaps we create an issue for this, if this saves a sizable amount of work. Done. https://issues.adblockplus.org/ticket/5340
I've proposed new changes. I think that these changes will make manual and automated ID and Comment generation and maintenance easier because it is less complex (a problem for automated generation) and ambiguous (a problem for manual generation and review). Note: I didn't put a lot of effort into the text because I want to respond to questions/concerns about this format first (I don't want to waste time). 
|
