UPDATE:
(Ez az egész komment egy update (annyiszor átírtam már).)

Megpróbáltam kideríteni, hogy hogy kerülnek oda a nyelvválasztó linkek; végigkövettem a dolgot a /modules/locale/locale.module-től (ő adja a nyelvválasztó blokkot) a /includes/language.inc-en keresztül vissza az i18n.module-ig.

Azt találtam, hogy olyan van, hogy az éppen megjelenített útvonal lefordított párját keresi. Ha ez egy views útvonal, akkor azét. (Ez az i18n.module 496. sorától kezdve látható)

Az megoldás felé vezető kérdés, hogy rá lehet-e venni, hogy más szempontot vizsgáljon; illetve hány helyen változhatnak meg az összetevők, mielőtt az i18n_get_path_translations($path) sorrakerül. Vannak ugyanis potenciális hookok, amik esélyesek beavatkozni errefelé, illetve változók, amik igen kacifántos úton kaptak értéket, mire idáig eljutottak.

De hogy őszinte legyek, ebben a pillanatban elég nagy kihívás lenne felelősségem teljes tudatában feltérképezni, hogy az összes lehetséges összetevő hányféle helyről jöhet össze azon a környéken.

Az alapján viszont, amit láttam, elég sanszosnak érzem, hogy lehet olyan modult készíteni, ami:

1. előállítja a views által éppen prezentált node path-ját
2. majd egy hookon keresztül azt valahol visszajuttatja a folyamatba (akár a fordítás keresése előtt (hagyva az i18n-t hogy megkeresse a fordítást), akár a már lefordított útvonalat)

...mielőtt az kiér a blokkba.

Úgy tűnik, hogy ehhez hasznos hookok vannak a /modules/system/language.api.php fájlban.

(Persze mindezt úgy, hogy az i18n_redirect modul is használható maradjon...)

Úgy adódott, hogy ismét vegyes composer / manuális telepítéssel kellett foglalkoznom. Tudom, már nem nagy segítség, de leírom, hogy mások is tanulhassanak belőle.

Ekkor jutott eszembe egy nagyon fontos dolog, amit itt elfelejtettem megemlíteni, de lényeges.

Amikor a composer külső php könyvtárakat telepít azt be kell csatolnia a drupal rendszerébe.

A vendor mappa composer mappájában több autoload_ névvel kezdődő elnevezésű php fájl található.

Ezekbe a települő könyvtára regisztrálják magukat, így kapcsolódnak a drupal rendszeréhez.

Miket és hova? Nos erre utal a composer.json fájl az adott php könyvtár mappájában, de az autoload_static.php, már trükkösebb.

Így a következőt javaslom:
Csinálj egy teszt drupal telepítést. Telepíts fel composer segítségével egy tetszőleges modult, aminek nincsenek további függőségei. Ekkor sok egyéb könyvtár is kerül a vendor mappába, amire a composer-nek szüksége van. Így könyebb lesz az összehasonlítás a későbbiekben.

Akár az egész vendor mappáról készítsünk egy másolatot mondjuk vendor_1 néven (itt, már benne lesznek a composer által igényelt könyvtárak is).

Tehát most telepítsük a tesztrendszerre a composer segítségével a valóban számunkra szükséges modult. Miután feltelepült, már kideríthető mik azok a könyvtárak, amelyek felkerültek az előző állapothoz képest.
Az újonnan felkerült könyvtárakat fel lehet másolni az éles rendszerre.

Következő lépésben az autoload fájlokat hasonlítsuk össze az előzőekkel. Így megállapítható melyek azok a plusz sorok, amelyek bejegyzésre kerültek.
Az éles rendszeren is módosítani kell a megfelelő autoload fájlokat és beírva a z új sorokat, máris működni fog minden.

Nagyjából így teljes a leírás.

Ha picit alaposabban tanulmányozza valaki a telepíteni kívánt könyvtárak függőségeit a kívánt könyvtárak composer.json fájljait és az autoload_static.php felépítését. Hamar észreveheti, hogy miként kell eljárni és akkor az összehasonlítás nem szükséges.

Úgy gondolom, hasznos lehetne, hasonlóan a "remove" és a "purge" közti különbséghez. Csökkentené az adatbázis működését, ez pedig adott esetben gyorsabb működést eredményezhetne.
Persze, az már egy másik kérdés, milyen módon biztosítható ilyenkor az adatbázis integritása...

Pontosan így van, akárhány validate és submit függvény lehet egy űrlapra kötve. Ez például a (biztonsági) frissítésnél nagyon jó, mert nem kell újra megnézned, hogy az újabb Drupal verzióban változott-e az adott függvény, hiszen az úgyis meghívódik.