Module talk:translations

Script error on Kazakh translation without transliteration

When I tried to add a Kazakh translation WITHOUT transliteration to how_much#Translations, I was getting a "script error" in red. Other languages worked fine, Kazakh also worked WITH transliteration. --Anatoli ^{(обсудить}/^вклад) 00:33, 1 July 2013 (UTC)

I fixed it now. See WT:Grease pit/2013/June#Module:translations for more information. —CodeCat 00:36, 1 July 2013 (UTC)

The value in "Page name" is ignored in preview

"Page name" seems to be ignored in the preview mode. When adding Kazakh and Slovene translations to how much does it cost the "?" wasn't visible in the preview. After saving I saw it was fine, though, Kazakh result (with "alt"): бұл қанша тұрады? (bul qanşa turadı?). The script error above persists. --Anatoli ^{(обсудить}/^вклад) 00:57, 1 July 2013 (UTC)

The script error is gone, thanks, only preview, please --Anatoli ^{(обсудить}/^вклад) 00:59, 1 July 2013 (UTC)

What is going wrong exactly? I don't really understand it because this is a problem with the translation editor, not this module. —CodeCat 01:00, 1 July 2013 (UTC)

Never mind... I fixed it. It was kind of stupid... —CodeCat 01:02, 1 July 2013 (UTC)

Category:Translations which need romanization

What's going to happen with Category:Translations which need romanization? --Anatoli ^{(обсудить}/^вклад) 03:14, 1 July 2013 (UTC)

"needs_translit"

Needing transliteration does not depend on what language the text is in, but the script. --Z 07:29, 1 July 2013 (UTC)

This is how it was done in the templates. —CodeCat 12:39, 1 July 2013 (UTC)

So? It's a mistake, no matter where it comes from. --Z 16:07, 1 July 2013 (UTC)

Well, there are some languages that use a non-Latin script but which don't need a transliteration. So it doesn't depend entirely on the script. —CodeCat 16:15, 1 July 2013 (UTC)

"alt" is not used

In functional#Translations "функционировать" is the lemma but the translation should display the participle "функционирующий", the value for alt, same with действовать/действующий:

• Russian: функционирующий (ru) (funkcionírujuščij), действующий (ru) (déjstvujuščij)

--Anatoli ^{(обсудить}/^вклад) 00:12, 2 July 2013 (UTC)

It looks ok to me... What is the problem? —CodeCat 00:40, 2 July 2013 (UTC)

Strange but it looks OK here now. I promise it displayed "функционировать" and "действовать" before. I have just saved "functional" (with no change). It seems to have fixed it, although it's worrying why it displayed "функционировать" and "действовать" before that. --Anatoli ^{(обсудить}/^вклад) 00:45, 2 July 2013 (UTC)

When I fixed the problem above, it didn't immediately update all pages. It takes some time, especially when there's a lot. —CodeCat 00:46, 2 July 2013 (UTC)

Thanks again. Anatoli ^{(обсудить}/^вклад) 00:57, 2 July 2013 (UTC)

Stripping exclamation/question marks

What do you think of having the module automatically strip ¿ ¡ ? ! ？！‽ from translations (exclamation and question marks, ditto upside down, ditto fullwidth encoding, and interrobang)? There are so many mistaken uses of these characters in translations... although perhaps this should go in Module:links as well, I don't know. —Μετάknowledge^{discuss/deeds} 20:45, 30 July 2013 (UTC)

Module:links already strips these characters from page names as far as I can tell, in the same way that it strips diacritics. So translations that contain them shouldn't be a problem, and we certainly don't want to remove them from the displayed text. —CodeCat 21:39, 30 July 2013 (UTC)

I didn't actually check the module, just noticed the problem in entries. I guess this is another case of lag? —Μετάknowledge^{discuss/deeds} 22:36, 30 July 2013 (UTC)

Extra space

t adds an extra space at the end when no gender is given:

{{t|en|word}}, > word,

(It had been fixed after this) --Z 20:39, 6 August 2013 (UTC)

BTW, I think the module should return script error when lang is en. --Z 20:44, 6 August 2013 (UTC)

The second parameter (term)

The second parameter (term) is currently required. We have translations like this Manchu one, that are just transliterations. I think we should keep these translations, and instead make the second parameter optional, but specifying "tr" should be required in that case. So: the first parameter (language code), as well as either the second parameter or "tr" should always be specified. --Z 15:25, 23 August 2013 (UTC)

The module should probably be converted to use Module:links at some point. Then we will get this "for free". —CodeCat 15:44, 23 August 2013 (UTC)

Some proposed changes

1. The module should throw an error when it is used in main namespace and given an appendix-only language, as proposed at User talk:Kephir/gadgets/xte#Random stuff.
2. The module should check whether the translation is in an acceptable script, and flag it for attention when it is not.

Keφr 11:39, 6 September 2013 (UTC)

Your second point would really be for all links wouldn't it? At the same time though, script detection is not perfect and probably will never be. —CodeCat 11:45, 6 September 2013 (UTC)

If this means false negatives only, it does not matter. False positives would be an actual problem. Keφr 11:50, 6 September 2013 (UTC)

When you say throw an error/flag it for attention, do you mean to use error(), or to display a small custom message and/or categorize the page in a dedicated category? I don't know what is the current standard here. Dakdada (talk) 13:58, 6 September 2013 (UTC)

Whichever would work better, but I had the latter in mind. On a related note, how is this going? Keφr 14:20, 6 September 2013 (UTC)

interwiki_langs

Is there any reason the cmn, nan, nb, rup and kmr conversions aren't also handled here? - TheDaveRoss 17:09, 31 December 2015 (UTC)

thesaurus

@Benwing2, @Justinrleung, @Rua, @Erutuon like {{synonyms}}, it would be helpful if {{t}} could generate links to thesaurus. something like ''see [[Thesaurus:TERM]]'' or ''see also [[Thesaurus:TERM]]'' (in case a few synonyms ar e given before then see also; a parameter |also=1 would be ok for this). eg in page morning i would like to give Thesaurus:प्रभात as the sanskrit translation; one can see the thesaurus page for transliterations & genders — Svārtava • 15:02, 10 August 2021 (UTC)

@svartava I would rather have a new template for this. Adding this to {{t}} will affect an awful lot of pages and potentially lead to memory errors. Benwing2 (talk) 01:23, 11 August 2021 (UTC)

@Benwing2 'kay; i created {{t-ws}} for it. you might want to edit it.. — Svārtava • 07:34, 11 August 2021 (UTC)

Add |to= and |as=

@Benwing2, Atitarev, DCDuring: Following up on User_talk:Atitarev#Phrasebook_gender: Per Wiktionary:Votes/2022-01/New_phrasebook_regulations, the following is now official policy: "If a translation of a phrase depends on the natural gender of one person, the corresponding gender must be denoted using the designated argument of {{t}}." Using the usual gender parameter for this purpose is an abuse thereof, an abuse of notation, but continuing to use {{q|male speaker}}/{{q|to a male}} etc. is also untenable in my opinion: 1. It's not reliably parseable 2. it's not stylized consistently ({{q}} occurs sometimes before, sometimes after a translations, contains varying wordings etc.) 3. it's more to type. Therefore, I propose adding |to= and |as= as new parameters, and I further propose that {{t|ro|ești căsătorit?|to=m}} be displayed as "ești căsătorit? (to a male)" or "ești căsătorit? (to m)" and {{t|ro|sunt căsătorit|as=m}} as "sunt căsătorit (as a male)", "sunt căsătorit (male speaker)", or "ești căsătorit? (as m)". I'm not married (heh) to any of these displaying styles, I just strongly believe that this whole thing should be documented as parameters, not as non-standardized qualifiers. — Fytcha〈 T | L | C 〉 11:52, 6 March 2022 (UTC)

Can you estimate how many of the abuses exist? IOW, is the problem worth "solving"? In which languages? IOW, should native speakers be involved? Who added these translations and the offending indications of natural gender? Have they all been involved in the discussion? DCDuring (talk) 15:13, 6 March 2022 (UTC)

There seem to be instances in which natural gender arises in definitions, ie, the headword is spoken by or to only a person of a specific natural gender. The headword is not necessarily in the phrasebook or a phrase of any kind and abuse of {{g}} is not necessarily involved. Rather than create a solution limited to translations, wouldn't it be better to do something that was at least somewhat consistent across entry sections, templates, etc.? For example, we could use "to=" and "as=" in {{lb}} to standardize presentation in definitions. This is not a discussion to be conducted on this page. It is at least a BP discussion. Whether a vote is required would be indicated by the nature of the discussion. I hope not. Simply applying the standardized approach where definitions or translation sections contain {{g}} or phrase like "to a male|female", "by|from|as a male|female" (which can be identified by reqex (insource) searches would be straightforward, although not a quaranteed-complete solution. Simply searching for those phrases (8 variations) would provide a count, possibly be language, and might identify locations of occurrence other than definitions and translations, eg, usage notes, etymologies. DCDuring (talk) 15:46, 6 March 2022 (UTC)

The "a" in "to a female" is optional. Regexes can easily be written to reduce the number of searches needed, possibly to exactly one, though at the cost of missing some unanticipated, but relevant, instances. DCDuring (talk) 15:57, 6 March 2022 (UTC)

@Fytcha: Your proposals seem interesting. Then, the split by formal/informal could also be covered by new parameters? Yes, it seems a discussion for BP. --Anatoli T. ^{(обсудить}/^вклад) 21:38, 6 March 2022 (UTC)

{{t+}} with multiple alt forms using //

@theknightwho would you mind fixing the issue? This has been a problem for quite some time now. This should be trivial to implement by adding additional checks for the link target in line 61.– Wpi (talk) 15:50, 18 June 2023 (UTC)