FANDOM


  • Hello, I am a person who want to translate articles in this wiki (as not only a Japanese helper but also one user of Dev wiki).

    There are some suggestion to i18n.

    1) Using Template:LangSelect in basepage.
    We can see our own language page (if it exists) without clicking the link of your language name even if your language is not English.
    Example
    2) Using Template:LangSwitch to make i18n templates.
    Example
    3) Making PAGENAME/base as a template to translate the page.
    I would like to ask which do you think is better, making PAGENAME/base or not to translate.
    Making /base template page (in article namespace) is so troublesome and maybe it doesn’t seem nice for English-only users.
    But making the /base page can keep newest information in all translated pages (even though some information would be shown in English).
    Example
    4) Which do you think is better to translate templates in Dev wiki?
    5) I heard there is a nice template to i18n.
    Template:Infobox_JavaScript/fng
    See also: User_talk:Plover-Y#New_page_format
    Technical info
    MediaWiki:Lang/xx mediawiki pages should be added to use some i18n templates in all languages. Thanks to KockaAdmiralacさん, it's solved!


    There is a list what we haven’t been able to use in Fandom but nice references to i18n.

    Thank you for reading this long and written in poor “Engrish” message. --Plover-Y (talk) 2017-11-21 12:44 (UTC)

      Loading editor
      1. LangSelect and LangSwitch certainly make things easier for translating, though it would be kind of weird if only that template was used on an article page (we would get a lot of invalid short page entries). The article page could look like:
        <noinclude>{{LangSelect}}</noinclude><includeonly>Contents that would usually be on PAGENAME/base</includeonly>

        so we don't have to create a lot of /base pages. Also, can the LangSelect template automatically add a template similar to {{Languages}} but with ?uselang=xx links instead of /xx? Would that render {{Languages}} deprecated?
      2. Sounds like a good idea. Have we considered having a collection of common translations that can be invoked with a Lua module, though? It would help in not duplicating translations, and if we store that collection in a JSON page we'll also be able to edit it with the translations editor and use it from scripts.
      3. I'm fine with having the base template but, as mentioned above, I feel like it's better if we keep the base template on the same page as the LangSelect template.
      4. If there's more than one string to be translated in the template, I think we should use the /base subpage, otherwise it can be put directly onto the template page.
      5. fngplg's infobox can be used on article pages and it pulls most infobox parameters from the parent page, so the infobox on translation pages does not have to be used with most parameters. If we do implement base templates on all article pages, though, I suppose that would be unneeded.

      I think it's also worth noting that I18n-js is a really useful library for scripts. It allows storing translations outside of code, not having to submit code for review when translations are added (it also makes JS reviewing Staff lives easier), it has a nice editor for translations and people don't have to bother updating the Languages parameter in the infoboxes on their documentation pages because putting "auto" in the Languages parameter will automatically list all languages it's translated to.

      I'll think about more possible things to note later, but it would really be great if we heard opinions of more users!

        Loading editor
    • 1. and 3.

      Using the root page for the base template too sounds like a great idea. Only drawback I see is it's a bit fiddly with the preview when editing the base template, though it not that big of a hassle. A comment with a tip about it should be enough for the most part I think. Like:

      <!-- If you want to preview the template while editing, simply "break" the <includeonly> tag while you're working on it. Just remember to put it back together before publishing.
      --><includeonly>Contents that would usually be on PAGENAME/base
      </includeonly><noinclude>{{LangSelect}}</noinclude>
      

      As for the ?uselang=xx links it's no problem. I remade Module:Languages so it's easy to add other formatting methods. One that adds displays uselang links instead of generated bluelinks, while leaving redlinks intact, will be quite simple. And it can be built-in into LangSelect (which in fact just invokes another formatting method of M:Languages).

      2. and 4.

      I'm not sure templates as subpages are viable. You have to keep in mind that LangSelect uses a DPL query to get list of subpages. Making templates use this system is no problem (just add page parameter to the invoke), but it'll will run a query for each one, to see what langs are available (this can be cached, though). Having LangSelect won't work with base template on the same page as both would have to be includable (or we could have a template to invoke such templates)

      LangSwitch should do the better job here. Combining it with variables would allow for cleaner code with all strings defined at the template start.

      {{#vardefine:some-string|{{LangSwitch
      | en = Lorem
      | de = Ipsum
      | fr = Dolor 
      | pl = Sit
      | ru = Amet}}}}
      
      <div>{{#var:some-string}}</div>

      LangSwitch also has the lang parameter that can also be combined with a variable. So instead of having to add |lang=pl in every template used on a Polish page, there could simply be a {{#vardefine:uselang|pl}} at the top, and all instances of LangSwitch will use that language or its fallback. Off course that variable can be built into LangSelect.

      When it comes common translations, it might be worth checking out, but I'm not sure we'd get many that are context-independent. Stuff like infobox labels etc. can work, but I wouldn't count much on anything beyond basics.

      5.

      It's a useful template, but as Kocka said, it becomes redundant with base templates, and it seems that's the direction.

        Loading editor
    • 3) isn't it overcomplicated for translators? there are guys that translates parameter names in the docs. how would they edit template? i mean we have translation errors even in the sample page rollback/es: |2017-08-11 = 11 August 2017<br/>9 March 2017 or |infobox-scope-personal = Personal.

      there must be more clear way to create doc pages. 1st looks easy enough.

        Loading editor
    • Thanks!

      about 3), I think we have to make doc if we use /base subpage to translate, too.

      Sorry, but I haven’t finished fixing non-English pages yet.

        Loading editor
    • template:updated added. u can implement this method in module in order to use autoupdate for updated field (smth like "if updated=auto then...") using path to script.

      here is example: commentPreview.

        Loading editor
    • I’ve edited Rollback and Rollback/xx with your advices above.

      I’ll edit i18n templates when I am not busy.

        Loading editor
    • > there must be more clear way to create doc pages

      Would you please edit this documentation (and the template itself) if it is not enough?

        Loading editor
    • Very impressed at {{Script Install}} and {{Script Install/base}} - much easier to read, now that the layout and translations are separate :)

      EDIT: Removing redlink.

        Loading editor
    • Plover-Y#8
      Would you please edit this documentation (and the template itself) if it is not enough?

      is there documentation for pagename/base method?
        Loading editor
    • I meant "Usage" section of parameters, but making language pages also sounds nice (^-^)/

        Loading editor
    • Cqm

      As someone who maintains scripts, i18n is a nice bonus, but making it harder for people who maintain scripts to find the documentation they want to update is a terrible idea. A page with merely {{LangSelect}} is incredibly counter-intuitive. Resorting to URL manipulation (because the link doesn't work) is not how the workflow of updating documentation should ever be. I strongly suggest a reconsideration on how the template works for maintainers be taken lest updating documentation becaomes a pain and they simply stop doing it.

        Loading editor
    • I know it’s harder to fix also typo...

      If you know good way to make i18n pages easily without Translate extension, please tell me (^-^)/

        Loading editor
    • if there is a choice between old format (en/subpages) and base/i18n with "where is documentation and how to edit it?" then i'm will choose former one.

      note: there is still no clear documentation about what and how to do with those templates. as one of maintainers, i'd like to see how to i supposed to write my docs.

        Loading editor
    • If Staff allows, we can make the edit/history buttons point to respective language subpages on pages using {{LangSwitch}} with JavaScript, so people can easily edit what they are seeing.

        Loading editor
    • @Kocka: I doubt it, unfortunately.


      The notice about where the page content is included from (currently at the bottom) can be moved to the top (notice=top) or be displayed in both places (notice=both). Do you think this would help?

        Loading editor
    • note: there is still no clear documentation about what and how to do with those templates. as one of maintainers, i'd like to see how to i supposed to write my docs.

      I made example documentations of "pagename/base" ―― in the way in w:c:wlb.

      • [[PurgeButton/base]]
      • [[Rollback/base]]
        Loading editor
    • Ninjamask
      Ninjamask removed this reply because:
      found it
      06:18, December 22, 2017
      This reply has been removed
    • This is a list of i18n templates.

      Sorry, but I don't know how to show language navigation in some pages of i18n templates using langswitch like [[Template:Script_Install/ImportJS]].

        Loading editor
    • Bump. Is there anyone able to look at modifying {{LangSelect}} behaviour, so that it only transcludes subpages on non-English articles? Also making sure it adds {{LangSwitch}} by default (or when supplied parameter is en)?

      I'm still not used to /en subpages like on Gekkou..

        Loading editor
    • Speedit wrote: Bump. Is there anyone able to look at modifying {{LangSelect}} behaviour, so that it only transcludes subpages on non-English articles? Also making sure it adds {{LangSwitch}} by default (or when supplied parameter is en)?

      What would be the point of LangSelect if it does not transclude the translated subpage on the base article based on user's language?

      Also, Staff answered long ago that writing JS to replace the URLs in the edit button and its dropdown on pages with LangSelect with URLs to pages related to the translation subpage you're currently viewing would be allowed, I just haven't gotten to writing such a script yet...

        Loading editor
    • Great. It's going to need to change edit links inside the article too~

        Loading editor
    • Hello, as some have been out of the Discord loop, here's some (late, sorry! ^^;) updates about i18n work and investigation:

      • We wrote Module:I18n to allow central datastores and separate i18n from Template namespace. Is this something you'd like in templates?
        • Example: Module:Install/i18n
        • We can return I18n from modules too! (Module:Install)
        • Perf is a blistering 0.050s for a dozen message calls - seems marginally faster.
      • We've tried JSON as datastore but the content perf isn't very great - there isn't a way to cache that data between calls. :c
      • We hammered out some bugs in LangSelect :)

      So far, we await a rewrite of I18n-js editor to improve other things and add Lua support.

        Loading editor
    • I hope this doesn't come across badly (the i18n module looks good in and of itself!), but might handling it all in Lua be unnecessary?

      For templates, since we have an "open" MediaWiki namespace (i.e. anyone can edit it), could it be simpler to use MediaWiki's built-in system to create messages as pages (e.g "MediaWiki:Custom-i18n-import-combination" with English text, "MediaWiki:Custom-i18n-import-combination/fr" with French text, etc.) and use, for example, {{int:Custom-i18n-import-combination}} in the template?

      This'd completely avoid the extra overhead of parsing messages in Lua, or the need to re-implement things like arguments, markup, language fallbacks, etc. If {{int:message}} is too limited, you could sill use a module with Scribunto's mw.message library as the interface instead, rather than having to implement it all yourself.

        Loading editor
    • Cqm

      Personally, I like having separate files for translations for traceability rather than arbitrary pages that are more difficult to track. It also makes it easier to integrate the editor into them.

        Loading editor
    • (I don't know why, but when I initially replied here my reply wasn't showing up so I'm replying again)

      OneTwoThreeFall wrote: For templates, since we have an "open" MediaWiki namespace (i.e. anyone can edit it), could it be simpler to use MediaWiki's built-in system to create messages as pages (e.g "MediaWiki:Custom-i18n-import-combination" with English text, "MediaWiki:Custom-i18n-import-combination/fr" with French text, etc.) and use, for example, {{int:Custom-i18n-import-combination}} in the template?

      Does {{int:}} cache better than Lua? If so, we probably won't have problems performance-wise. One possible problem I see with {{int:}} is that it will display the content in user's language regardless of the language of the current article (it will display the some translations in French on an English article to a user that has their language set to French) which may look inconsistent, but I don't know how much of a real problem would that be (especially as we're going towards {{LangSelect}}'d pages)

      Another problem I see with it is that it might be easier for translators to put all translations onto one page instead of onto multiple pages. However, if we make I18nEdit able to edit these kinds of translations (as we already planned to do for Lua translations eventually), it might make things easier.

        Loading editor
    • Cqm wrote: Personally, I like having separate files for translations for traceability rather than arbitrary pages that are more difficult to track. It also makes it easier to integrate the editor into them.

      Fair enough! If pages were to be used, some sort of index for them would be useful. The editor could then use this index, with a prefix search used to list existing translations for each page.

      KockaAdmiralac wrote: Does {{int:}} cache better than Lua? If so, we probably won't have problems performance-wise.

      No idea about performance or caching, though I imagine parsing messages in Lua would be slower than the usual PHP code, since that's likely well optimised due to being used so extensively.

      One possible problem I see with {{int:}} is that it will display the content in user's language regardless of the language of the current article (it will display the some translations in French on an English article to a user that has their language set to French) which may look inconsistent, but I don't know how much of a real problem would that be (especially as we're going towards {{LangSelect}}'d pages)

      That's why I mentioned the mw.message Lua library, which allows a little more control like that.

        Loading editor
    • (Late rip) A central datastore would also make a change like Special:Diff/79525 quick to implement. There's a small perf hit, but we do get benefits like not treating 'uk' and 'ru' as interchangeable (WMF phab).

        Loading editor
    • About Help:Volunteer Developers and Lua templating pages, are there better ways to indicate links to other languages' help pages?

        Loading editor
    • I like that they merge base-page and /en subpage. But I have a problem by the editing, too.

      About https://dev.wikia.com/wiki/PseudoMonobook ,

      1) is easier to translate... Are there any good solution to store parameters with English texts?

        Loading editor
    • Did you try click "日本語" in the Languages dropdown and press "Save"? That generates the right English translation, no matter what method the developer used to i18n.

        Loading editor
    • It seems nice !! Thank you!


      Anyway, there is no “日本語” in the dropdown because of my language setting in Fandom... So (maybe) I didn’t notice that...

      P.S. Thank you so much for updating project:I18n !

        Loading editor
    • A FANDOM user
        Loading editor
Give Kudos to this message
You've given this message Kudos!
See who gave Kudos to this message