<p dir="auto">In THREE.js the repeat (tiling) property is bounded to the texture object, and personally I think it's a mistake. texture tiling will have much more flexibility if it would be a material property. for example, it's very common for a user to want to load a single texture and tile it differently on different surfaces, based on the size and proportions of each surface. but if repeat is part of the texture you are forced to duplicate the texture itself, which doesn't sound very efficient.</p>
<p dir="auto">the fix I propose is very simple - add a repeat property to the material itself, which will override the 'repeat' of the texture if it's not undefined. I did this two-lines patch in my THREE.js project and it works well.</p>
<p dir="auto">what do you think?</p>
<p dir="auto">thanks</p>
<p dir="auto">Given prior decisions...</p>
<ul dir="auto">
<li>Maintain <code class="notranslate">.d.ts</code> typings, do not convert to TypeScript. (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="396884431" data-permission-text="Title is private" data-url="https://github.com/mrdoob/three.js/issues/15545" data-hovercard-type="issue" data-hovercard-url="/mrdoob/three.js/issues/15545/hovercard" href="https://github.com/mrdoob/three.js/issues/15545">#15545</a>)</li>
<li>Keep JSDoc and default values in <code class="notranslate">d.ts</code> files, not source code. (<a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="665006007" data-permission-text="Title is private" data-url="https://github.com/mrdoob/three.js/issues/19919" data-hovercard-type="issue" data-hovercard-url="/mrdoob/three.js/issues/19919/hovercard" href="https://github.com/mrdoob/three.js/issues/19919">#19919</a>)</li>
<li>Support i18N in documentation.</li>
</ul>
<p dir="auto">... I think there might be an easier option to maintain documentation, typings, and support i18n. The basic workflow would be:</p>
<ol dir="auto">
<li>Put full documentation (not just default values) in the JSDoc in <code class="notranslate">.d.ts</code> files.</li>
<li>Allow translators to use <a href="https://www.npmjs.com/package/jsdoc-i18n" rel="nofollow">jsdoc-i18n</a> to maintain text translations in a simple sqlite file.</li>
<li>Generate documentation — and all translations — from the sqlite file.</li>
</ol>
<p dir="auto">One advantage of this is that the documentation and typings are in the same place. I suspect it will also make things much easier for translators, but — to be clear — I don't know how robust json-i18n's workflow is. You can find some discussion of this on <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="121991091" data-permission-text="Title is private" data-url="https://github.com/jsdoc/jsdoc/issues/1127" data-hovercard-type="issue" data-hovercard-url="/jsdoc/jsdoc/issues/1127/hovercard" href="https://github.com/jsdoc/jsdoc/issues/1127">jsdoc/jsdoc#1127</a> and <a class="issue-link js-issue-link" data-error-text="Failed to load title" data-id="254940895" data-permission-text="Title is private" data-url="https://github.com/documentationjs/documentation/issues/899" data-hovercard-type="issue" data-hovercard-url="/documentationjs/documentation/issues/899/hovercard" href="https://github.com/documentationjs/documentation/issues/899">documentationjs/documentation#899</a>.</p>
<p dir="auto">The other effect of this, which could be a downside depending on our preferences, is that it does require a build step for generating the documentation. It's entirely possible to include headers and example code in JSDoc (<a href="https://github.com/donmccurdy/glTF-Transform/blob/e0ccb0ea85976e7425c909c2ead1ffe81051d975/packages/core/src/document.ts">example</a>) but this may still limit the customization possible on individual docs pages.</p>