Opened on 03/13/2015 at 02:14:13 PM

Closed on 04/23/2015 at 03:25:40 PM

Last modified on 05/07/2015 at 11:52:44 AM

#2139 closed change (fixed)

[cms] Allow nested translations for tag attributes

Reported by: trev Assignee: kzar
Priority: P3 Milestone:
Module: Sitescripts Keywords:
Cc: Blocked By:
Blocking: #2140 Platform: Unknown
Ready: yes Confidential: no
Tester: Verified working: no
Review URL(s):

Description (last modified by kzar)


Currently, you have no way but to break up a string if a link needs to be translated:

{{str1 There is more}} <a href="{{link}}">{{str2 information}}</a> {{str3 available on this.}}

This is very suboptimal as the three parts of the sentence have to be translated separately.

What to change

Allow nested translations, for tag attributes, so that something like this will work:

{{str There is more <a href="{{link}}">information</a> available on this.}}

So only the string There is more <a>information</a> available on this. should be translated in addition to the link target.

Note. Translations are not allowed to alter the order of tags in the string, so we do not need to handle that.

Attachments (0)

Change History (10)

comment:1 Changed on 03/13/2015 at 02:16:06 PM by trev

  • Blocking 2140 added

comment:2 Changed on 04/10/2015 at 03:21:26 PM by kzar

  • Owner set to kzar
  • Verified working unset

comment:3 Changed on 04/13/2015 at 06:33:27 PM by kzar

@palant Do we only care about nested translations because we want to allow translatable URLs in links? If so how about we do this instead:

  • Pick some arbitrary prefix for URLs in page templates that indicates that they are translatable. For example we could pick "!" so your example would look like {{str There is more <a href="!">information</a> available on this.}}. (Or a Markdown equivalent would look like {{str There is more [information](! available on this.}}.)
  • Store translatable links in locale files as an array along with their corresponding text. So to continue our example a locale file might look like {"str": {"message": "There is more <a>information</a> available on this.", "links": [""]}} instead of {"str": {"message": "There is more <a>information</a> available on this."}, "link": {"message": ""}}. I think that would make much more sense and be easier for translators to understand, otherwise it's going to get confusing fast trying to keep track of which translation strings correspond with which translatable URLs. (In any case we would have to come up with some convention like "str_link_1" for the string names of translatable links.)

What do you think?

comment:4 Changed on 04/13/2015 at 06:58:15 PM by trev

We currently only need this functionality for <a href="">, yes. However, I don't really like hardcoding this as a limitation of the system, meaning that <a title=""> will just not be possible. And what if we decide to allow images within localizable strings?

The proposed syntax also has disadvantages: while being visually simpler, it means introducing special syntax for this (rather uncommon) scenario. And I dislike that the string name cannot be specified explicitly - this will bite us at the latest when we get a string with two translatable links. No, we cannot just change the format of the locale files - Crowdin has to support it.

So altogether this doesn't seem to be worth it. We can limit this to full attributes however, things should be only marginally more complicated then.

Last edited on 04/13/2015 at 06:58:29 PM by trev

comment:5 Changed on 04/13/2015 at 07:22:26 PM by kzar

@palant Fair enough, next question then is how do we figure out where nested translatable strings should be placed inside the parent string for translations? It seems like we need some marker like {{child_str_name}} inside the parent string. So for example {"str": {"message": "There is more <a href='{{str_link_1}}'>information</a> available on this."}, "str_link_1": {"message": ""}}.

It seems like an unnecessary layer of indirection though, surely we might as well just have the nested string inside the parent string directly, so something like {"str": {"message": "There is more <a href=''>information</a> available on this."}}.

Thing is to allow that we would then be back to requiring a special syntax in the page template to indicate that an attribute is translatable. (Perhaps we could prefix translatable attributes with "!" or similar after all?)

comment:6 Changed on 04/14/2015 at 05:02:51 PM by trev

We already have that information in the page, we don't need to duplicate it in the string as well. If the page says {{Click <a href="http://foo/">here</a> or <a id="barlink" href="http://bar/">here</a> please.}} then the translatable string will be Click <a>here</a> or <a>here</a> please. So how does the code know where href="http://foo/" goes? Right, the first <a> tag, because that's where it is in the page. And where does id="barlink" go? The second <a> tag of course. That logic is already implemented - it only needs to be extended by translatable attributes.

comment:7 Changed on 04/15/2015 at 09:54:08 AM by kzar

  • Description modified (diff)
  • Summary changed from [cms] Allow nested translations to [cms] Allow nested translations for tag attributes

OK so after a discussion in IRC it turns out that translated texts are not allowed to change the order of tags. I didn't realise that, hence the confusion about how we'll know where translatable attributes get placed. Updated the ticket description to reflect my understanding.

comment:8 Changed on 04/16/2015 at 01:37:52 PM by kzar

  • Review URL(s) modified (diff)
  • Status changed from new to reviewing

(Whoops, forgot to set this as reviewing earlier!)

comment:9 Changed on 04/23/2015 at 03:25:40 PM by kzar

  • Resolution set to fixed
  • Status changed from reviewing to closed

comment:10 Changed on 05/07/2015 at 11:52:44 AM by kzar

Add Comment

Modify Ticket

Change Properties
as closed .
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from kzar.
Note: See TracTickets for help on using tickets.