Template talk:Ls

Русский: Парусски!

English: English

Instead of having the language code you should have {{#language:XX}} (XX = language code). pfctdayelise 12:11, 14 June 2006 (UTC)[reply]

Fixed. — Ambush Commander^(Talk) 17:02, 14 June 2006 (UTC)[reply]

#language[edit]

Should lanuage code be included too? Such as

  '''{{#language:ja}} (ja)'''

returns

日本語 (ja)

MaxSem 17:31, 14 June 2006 (UTC)[reply]

Right to left content[edit]

the template fails when I try to add a div/p/span/bdo tag with "rtl" dir parameter and thus renders only

العربية: {{{2}}}

any suggested solutions? maybe adding a dir variable in this template will help?. Thanks. --Mido 08:59, 13 December 2006 (UTC)[reply]

It does use "bdi" now for the inner message. (it has used previously "bdo" in a short period, but "bdo" is deprecated in favor of "bdi", which does not ovveride the direction of the content, (it suggests only the initial default direction) but still isolates the effective drection of the content from the direction of the outer context).

"span "and "div" are not usable as universal containers: a div for each language would break a longer span, and a span for each language could not contain translations embedding blocks ("div", "p", "dt" with leading semicolon, "dd" with leading colon, "li" with leading sharp sign or asterisk, or possibly tables...)

verdy_p (talk) 21:12, 30 January 2014 (UTC)[reply]

Optional span instead of div[edit]

I propose to add a parameter "span=yes" (default to "span=no") to create a container with a span tag instead of the div tag. The reason (at least one of the reasons) is the div container behaves badly in a header -- or perhaps it is normal by comparison with the norms but the final rendering is anyway bad. I tested on this page to emulate the {{ls}} template with a span and it works correctly with Opera and Firefox. ~ Seb35 [^_^] 19:36, 27 January 2014 (UTC)[reply]

Done in [1] and doc updated in [2]. ~ Seb35 [^_^] 17:10, 29 January 2014 (UTC)[reply]

Instead of the #if, you shoukd have used a tag parameter whose default value is "div", so that we could use "tag=span" to generate spans, or "tag=td" to generate table columns, or tag=li to generate list items, or tag=p to generate paragraphs, or "tag=blockquote" to create quotations, without having to specify these tags in the content of *each* translation.

Anyway the Ls template is the worst method available to translate pages (multilingual pages are very ugly with their language selectors occuring at each multilingual section of a page.

It is far better to use fully translated pages ,with:

the new Translate extension, once the base page has been marked as translatable by an admin, each subpage will contain only one language and language selection will be made with the top language bar)
or LangSwitch to use only the user's preferred UI language on all pages independantly of their content translation (LangSwitch is mostly used for simple banner notices, but all LangSwitch are also convertible to use the Translate extension, which simplifies a lot the edition of base templatesn and avoid damaging these templates by attempts made by candidate translators to decipher the template code and its layou).

Very frenquently the template authors are good only at developing it for their own language, trnaslators don't understand this code. And some other people will need to adapt the code itself (without modifying translations) in order to correct caveats occuring in some languages (such as sentences split in separate translatable items, that won't combine in the same order, or bugs occuring with the conversion of dates and numbers in the user's language or in the content language of a translated subpage.

The most common error made by template writers is to assume that it will have LTR reading order when the untranslated template is transcluded in a RTL page (and then they align images to the right side, or assume the direction of arrows and icons); more complex issues are in number and date formating performed in lots of legachy templates (such as those that assume that the numeric value returned by CURRENTHOUR (for example) is computable in #expr (this is false when the content language changes digits, decimal and grouping separators, or date formats returned by #time...)

verdy_p (talk) 21:02, 30 January 2014 (UTC)[reply]