Tag syntax is counter intuitive #826

Closed
opened 2019-03-08 07:34:27 +00:00 by reinhard · 10 comments
Member

The current tag format is <tag content="Label of the tag">Tag code</tag>.

However, for virtually everything else in the source files, text visible to the user (and thus subject to translation) is outside of <...> and everything inside <...> should not be translated. This leads to translators intuitively translating the tag code rather than the tag label.

I suggest to change the tag format to <tag name="Tag code">Label of the tag</tag>.

This would mean updating all source files with <tag>s in them, and updating the XSL code that actually reads the tags. I could certainly do the latter.

The current tag format is `<tag content="Label of the tag">Tag code</tag>`. However, for virtually everything else in the source files, text visible to the user (and thus subject to translation) is *outside* of <...> and everything inside <...> should not be translated. This leads to translators intuitively translating the tag code rather than the tag label. I suggest to change the tag format to `<tag name="Tag code">Label of the tag</tag>`. This would mean updating all source files with `<tag>`s in them, and updating the XSL code that actually reads the tags. I could certainly do the latter.
reinhard added the
tagging
xsl
build
labels 2019-03-08 07:34:28 +00:00
Member

Is there anything that speaks against the syntax <tag id="tag code">Label of the tag</tag>? I guess "name" as attribute could be misinterpreted as translatable content, especially since we are swapping the position of id and label...

Is there anything that speaks against the syntax `<tag id="tag code">Label of the tag</tag>`? I guess "name" as attribute could be misinterpreted as translatable content, especially since we are swapping the position of id and label...
Author
Member

I agree that id is better than name.

I agree that id is better than name.
Author
Member

After thinking about it again, I find myself strongly disagreeing with myself :-)

In HTML, the "id" attribute is always used to identify an element within the document tree, without any external meaning of the content of this attribute. If you look at attributes that contain a code which has any meaning other than addressing the element in the document tree, it is "name", as e.g. in <input name="...">.

So I go back to thinking that it should be <tag name="Tag code">Label of the tag</tag>, for the sake of being consistent with life, universe and all the rest.

After thinking about it again, I find myself strongly disagreeing with myself :-) In HTML, the "id" attribute is always used to identify an element *within the document tree*, without any external meaning of the content of this attribute. If you look at attributes that contain a code which has any meaning other than addressing the element in the document tree, it is "name", as e.g. in `<input name="...">`. So I go back to thinking that it should be `<tag name="Tag code">Label of the tag</tag>`, for the sake of being consistent with life, universe and all the rest.
Member

I get your point about the name clash with "id", however there are other options as well. How about any of these alternatives:

  • tagid
  • tag
  • identifier
  • staticid
I get your point about the name clash with "id", however there are other options as well. How about any of these alternatives: * tagid * tag * identifier * staticid
Owner

IIRC we also had the idea of using key when we discussed about it once

IIRC we also had the idea of using `key` when we discussed about it once
Member

key would work for me...

`key` would work for me...
Author
Member

I would still prefer name (from the analogy to the other HTML attributes which are called "name"), but key would also work for me.

I would still prefer name (from the analogy to the other HTML attributes which are called "name"), but key would also work for me.
Owner

Thanks for the input!

I agree to @jzarl that name might be misleading in this case for our translators, although there are similar examples in HTML. id would make the most sense for me, but I see @reinhard's point. So I'd go for key although it isn't perfect either.

Thanks for the input! I agree to @jzarl that `name` might be misleading in this case for our translators, although there are similar examples in HTML. `id` would make the most sense for me, but I see @reinhard's point. So I'd go for `key` although it isn't perfect either.
Member

So in lack of a perfect solution let's settle for the key one.

I've created an xsl transformation file that fixes the syntax for the xml files. (I've attached it because it probably doesn't make much sense to put it into git as it will only be used once).

We also need to change the existing build scripts to deal with the new syntax, but I haven't looked into this yet. If @reinhard doesn't beat me to it, I may have some time at the end of next week to continue working on this issue.

So in lack of a perfect solution let's settle for the `key` one. I've created an xsl transformation file that fixes the syntax for the xml files. (I've attached it because it probably doesn't make much sense to put it into git as it will only be used once). We also need to change the existing build scripts to deal with the new syntax, but I haven't looked into this yet. If @reinhard doesn't beat me to it, I may have some time at the end of next week to continue working on this issue.
Author
Member

Actually, most of the xsl scripts already handle the <tag key="..."> syntax, obviously this conversion has already been planned and prepared years ago, but never finished.

AFAICT, all you would need to change would be build/xslt/get_tags.xsl and tools/tagtool/tagsToCSV.xsl.

However, after the conversion, we can clean up a number of xsl script which cover both old and new syntax and do lowercase conversion of tag keys.

Actually, most of the xsl scripts already handle the `<tag key="...">` syntax, obviously this conversion has already been planned and prepared years ago, but never finished. AFAICT, all you would need to change would be build/xslt/get_tags.xsl and tools/tagtool/tagsToCSV.xsl. However, *after* the conversion, we can clean up a number of xsl script which cover both old and new syntax and do lowercase conversion of tag keys.
Sign in to join this conversation.
No Milestone
No Assignees
3 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: FSFE/fsfe-website#826
No description provided.