Op 29 okt 2010, om 14:51 heeft Magnus Manske het volgende geschreven:
On Fri, Oct 29, 2010 at 1:36 PM, Bryan Tong Minh bryan.tongminh@gmail.com wrote:
On Fri, Oct 29, 2010 at 2:25 PM, Krinkle krinklemail@gmail.com wrote:
For one, tags would not be hierarchical and not stored under a name, rather a number (an id if you will).
I would store the tag-i18n definitions in a separate Tag: namespace. Then you don't need to create the history tracking etc. all by yourself. You will need a unique identifier though, but I don't see a problem making the unique identifier equal to the content language.
As to "tracking", IMHO it would suffice to just add [[Tag:XYZ]] to the pages; that's rather inelegant from a database POV, but as Bryan points out, it would take care of version tracking etc. All one would need to do is to remove them from the rendering and display them separately, like categories.
@Bryan: Ah, excuse me. You were referring to the history of the File- page. I was under the impression it was about the version tracking of the Tags. Yeah, adding to the page would be similar to categories and extracted from wikitext to a taglinks table.
Multilanguage tags, as well as synonyms, could simply be implemented as #REDIRECTs, maybe. [[Tag:Blume]] would redirect to [[Tag:Flower]], so a search for "Blume" would know about "Flower" easily. However, the system would then have to search for both Blume and Flower internally. Also, that could be a problem with "false friends" (en:Gift=present vs. de:Gift=poison).
Though that's certainly not a bad option. I was thinking not to use page-title search when searching through tags. Instead the tag-table itself which contains all the i18n versions. An option on the tag-search page could specify whether the search should cover English( and/or user-language), or all languages.
Reason being that using redirects would practically mean we are supposed to keep all redirects in-sync with the tag-translations, which seems double work.
-- Krinkle