Käännöksen laadun kannalta on tärkeää, että kautta käännöksen käytössä ovat samat käännöstermit. Kootaan niitä tähän muille (ja itsellekin) avuksi ja muistutukseksi; jos olet jostain eri mieltä, jätä kommentti niin muutkin pääsevät mukaan avuksi vaikeisiin päätöksiin!

Tälle sivulle lienee tarkoituksenmukaista koota ensisijaisesti vain Drupalissa esiintyvää sanastoa; yleisempää sanastoa löytyy muista lähteistä (esim. http://lokalisointi.org/ .)

Käännöksiä

Dashboard
Työpöytä
Node
Solmu
Module
Moduuli
Input format, text format
Tekstimuoto
Entity
Entiteetti
Item
Ei yhtenäistä käännöstä, tilanteen mukaan
Taxonomy (vocabulary, term)
Luokittelu (sanasto, termi)
URL
URL, URL-osoite
Web address
Verkko-osoite
Token
Keskustelu käynnissä
Views (view, display)
Näkymät (?, näkymä)
Feature
Ominaisuudet
Display mode (view mode, form mode)
Esitystapa (näyttötila, keskustelu käynnissä)
Shortcut
Pikalinkki
Block
Lohko
Groups audience: 
Finnish team
⋅ Categories: fi-dokumentaatio

Comments

aalamaki commented

Hei,

Edelliseen vähän ehdotelmaa kun tuossa Drupal 8 on pääosin käännetty suomeksi ja olisi hyvä saada käännökset kerralla kuntoon.

Tuo sana "solmu" ei suomenkielessä tarkoita mitään. Ehdottaisin tuo ja pari muuta termiä jätettäisiin kääntämättä, nämä ainakin ensialkuun:

- node
- URL

Toinen johon pyytäisin kommentteja eli sanat "Token" ja "item" eli mikä olisi noille paras käännös? Token on käännetty "korvauskuvio" mikä ei tarkoita mitään suomenkielessä, kuulin ehdotuksen "korvattava merkkijono" mikä kuulostaa paremmalta mutta vastaako täysin kontekstia?

Item on sanana hankala, sille on käännöksissä käytetty "kohde" mutta joissakin konteksteissa tämä ei ole oikea käännös.

Kolmas asia, olen kääntäessäni jättänyt yhtenäisyyden takia kääntämättä verkko-osoitteet ja moduulien nimet koska tämä helpottaa moduulien löytämistä, onko ok vai muutetaanko käytäntöä?

Tämä keskustelunavauksena, kommentoikaa :)

tipit commented

Olen samaa mieltä, että node ja URL pitäisi jättää kääntämättä.

Itsekään en ole parempaa substantiiviä vielä tokenille löytänyt kuin "korvauskuvio". Mielestäni sanan ei tarvitsekaan tarkoittaa virallisesti mitään, kunhan sana on kuvaava eli palvelee tarkoitusta. "Korvattava merkkijono":lla kuvataan yleensä IT-kirjallisuudessa Stringejä ja se ei ole muutenkaan niin kuvaava tässä tilanteessa kuin esim. "korvattava teksti". Harmi sanoa, että "korvauskuvio" on edelleen paras käännös. :)

aalamaki commented

Käännös "korvauskuvio" on vain siitä hankala että se ei kerro normikäyttäjälle (sisällönsyöttäjä yms) mitään, sanan pitäisi olla jotenkin kuvaavampi tai sitten pitää saada kuvausteksteihin jotain asiaa paremmin avaavaa. Vaikka noh...itsepähän tuota tulin ensimmäisenä käyttäneeksi täällä kun ensimmäistä kertaa tein Token-moduulille käännöstä, mietin kyllä tuota moneen kertaan mutta en parempaakaan keksinyt kun ei sana "token" kääntämättömänäkään normikäyttäjälle mitään kerro.

wroxbox commented

Antin kanssa tästä eilen pitempään puheltiinkin ja korvauskuvio on siinä mielessä hankala, että eihän meillä ole mitään kuviota käyttöliittymässä nähtävänä joka pitäisi korvata.

Meillä on placeholder (paikkamerkintä?) ja korvattava merkkijono tai korvaava merkkijono riippuen kohdasta.

apassi commented

Mä olen vähän eri kannalla. Solmu on ollut drupalissa jo hyvin pitkään, joten ainakin mun suuhun se on jo sen verran iskostunut, että olkoot. Jos se ei nyt mitään järkevää tarkoita, niin sitten ei, IT sanasto on muutenkin niin paljon täynnä hepreaa ei alan ihmisen korviin.. Esim. olio, plymorphismi, perintä, yms.

Tuleekos D8:n entityt? onko sille jotain käännöstä?

URL- on alunperinkin lyhenne, joten se ei siinä mielessä merkitse mitään mitä voisi kääntää, korkeintaan se pitäisi olla niin että kääntää sen pitkän version ja sit lyhentää sen, en ole ikinä kuullut mitä se voisi suomeksi olla.

Tokenin suomennos voisi olla hyvin lähellä substituutiota, mutta siihenkin olen jo niin tottunut drupalissa, kun vuosia token esiintynyt..

aalamaki commented

"Solmu" on joo tosiaankin ollut pitkään, aikoinaan kun aloin tekemään D7 käännöstä niin ihmettelin koko termiä koska se ei todellakaan tarkoita mitään eikä vastaa mitenkään sanaa "node", jätin sen kuitenkin koska oli niin vakiintunutta termistöä mutta nyt D8:n tullessa olisi hyvä tilaisuus päivittää vanhoja käytäntöjä kun pakka menee muutenkin uusiksi.

Tuo "entity", se on käännetty jo D7:ssakin "kokonaisuus" joka on hyvin lähellä oikeaa käännöstä ja kuvaa aika hyvin sitä mitä se käsittää, en aikakaan itse sille parempaa keksinyt.

tipit commented

Entityn suora käännös on "Entiteetti", jota itse käytän. "Kokonaisuus" voi tarkoittaa niin montaa muutakin asiaa eli kun/jos olio-ohjelmointi-kontekstissa ollaan, niin sille voisi olla spesifimpikin nimi.

apassi commented

Komppaan entiteettiä, ymmärtää helpommin mistä on kyse jos vaikka joutuu jonkun kanssa puhumaan asiasta.

aalamaki commented

Hmm, ok odotetaan tähän ketjuun vielä muita mielipiteitä. Pyrin käännöksistä tekemään sellaisia että myös ei-tekninen ihminen ymmärtää niitä, pitää ottaa huomioon että esimerkiksi sisällönsyöttäjät harvemmin ymmärtävät tekniikan päälle. Tuo kokonaisuus on sanana kattavampi; itse vierastan muutenkin lainasanojen käyttöä.

Belham commented

Vaikka solmu terminä onkin monen meidän suuhun jo taittunut on se edelleen kohtalaisen absurdi ilmaus, ja käännöksenä turha. Kuitenkin 90% suomalaisistakin drupal devaajista puhuu nodeista, ei solmuista.

Entityn käännöksenä Entiteetti toimii parhaiten, koska suomen kielessä ei vaan ole sanaa joka ei sekottaisi ketään. Ei ole suomea? Nyt on. :)

wroxbox commented

Entiteetti on juurikin hyvä termi.

tormu commented

+1 entiteetille. Kokonaisuus kuulostaa jo mun korvaan lähemmäs bundlelta.

Ja noden kääntämättä jättämiselle ääni myös.

kari.kaariainen commented

Solmuahan kyllä käytetään ihan yleisestikin eri tieteissä ja teknologioissa noden käännöksenä - yleiskielen lisäksi - joten en ymmärrä tuota, että solmu ei tarkoita suomen kielessä mitään.

Itse ajattelisin näin: vaihtoehdot ovat solmu, noodi ja ehkä ylempänä ehdotettu node.

Hyvä ja huonot puolet nimenomaan käyttäjän/asiakkaan kannalta.

Solmu:
+suomea, taipuu ongelmitta
-negatiivinen mielikuva, jokin on solmussa
-jos asiakas ei tunne sanaa ennestään tietotekniikkamerkityksessä, on vaikea opettaa tälle yleiskielen sanalle uusi merkitys, varsinkin näin abstraktille asialle, kuin missä sitä Drupalissa käytetään

Noodi:
+johdettu latinasta samoin kuin moodi (modus-moodi, nodus-noodi)
+taipuu ongelmitta
-en ole varma, onko tällaista sanaa virallisesti suomen kielessä, mutta:
+uudelle sanalle on helpompi opettaa uusi merkitys

Node:
+välttyy kääntämiseltä
-ei ole suomea
-kuinka äännetään: "noud", "node"?
-kuinka taipuisi? "noudien", "nodejen"?

Omasta mielestäni noodi on vähän parempi kuin solmu.

wroxbox commented

En lähtisi missään nimessä vaihtamaan Nodea noodiin tai solmuun. Koska sille ei löydy oikeasti parempaa, pitäytyisin Nodessa.

Helpompaa kysyä esim asiakkaalta, "mikä on noden ID"

Kääntyy: Node, Noden, Nodet, Nodien (vaikkakin Nodejen on oikeasti oikea taivutusmuoto, mutta menettää taas merkityksen)

aalamaki commented

Samaa mieltä noden kohdalla...aikoinaan kun aloin corea kääntämään niin siellä oli tuo "solmu" vakiintuneena käytäntönä joten jatkoin silloin siitä.

Ehdottaisin että D8:n kohdalla jätetään kääntämättä, "solmu" tarkoittaa suomenkielessä ihan yhtä vähän kuin "node" englannissa (ei vastaa sitä mistä on kyse).

Tuollaisten kohdalla olisi parempi vain pitäytyä alkuperäisessä termissä jos parempaa ei ole tarjolla suomeksi.

zeip commented

Yleisesti keskustelussa on havaittavissa kahta koulukuntaa; niitä, jotka ajattelevat käännöstä Drupal-ammattilaisen silmin ja niitä, jotka ajattelevat sitä tavallisen tallaajan näkökulmasta. Oikeastihan pitäisi olla kaksi käännöstä; se mahdollisimman suomenkielinen versio joka voidaan antaa loppukäyttäjälle ja se, josta löytyy kehittäjälle englanninkielisistä keskusteluista tutut sanat.

Itse ainakaan en käytä suomenkielistä käyttöliittymää omassa käytössäni mielelläni lainkaan, ja olen vahvasti sillä kannalla että suomenkielinen käännös on nimenomaan tumpeloa loppukäyttäjää varten, jonka täytyy pystyä käyttämään järjestelmää ilman että käyttöliittymän kieli vaikuttaa heprealta.

Tätä kohti päästään sillä, että käytetään suomenkielisiä termejä – kokonaan vieraat termit eivät houkuttele lukemaan tekstiä vaikka ”tuttu” termi ei olisi yhtään sen kuvaavampi. Kehittäjien keskusteluahan käännös ei rajoita, vaan omassa puheessa työtovereiden kanssa voi hienosti käyttää niitä englanninkielisiä termejä. Yksi huomioitava pointti on myös se, että uskoisin käyttäjän muistavan todennäköisemmin lyhyestä ohjeistuksesta (tai vaikka virheilmoituksesta) sanan ”solmu” kuin ”node”, jos termit eivät ennestään ole tuttuja.

Koottuna omat suosikkini:

Node => solmu
– Myös noodi kävisi, mutta koska se on tähänkin asti ollut solmu, sopii sellaisena paremmin suomalaisen suuhun eikä vaihtaminen hyödytä uusia käyttäjiä (mutta haittaa vanhoja) niin en missään nimessä kannata vaihdosta.

URL => URL tai URL-osoite, tilanteesta riippuen
– Lyhenteenä tätä ei toki kannata lähteä kääntämään, mutta sellaisissa kohdissa joissa tilan ja merkityksen puolesta on soveliasta niin mieluusti lisäisin tuohon vielä osoite-sanan – tämä aivan siitä syystä, että vaikka URL ammattilaisille on selkeä käsite niin käännöksen varsinaiselle kohderyhmälle (peruskäyttäjät) se ei sitä välttämättä ole, ja tuo osoite-sana ainakin saattaa auttaa arvaamaan mitä tarkoitetaan.

Token => korvauskuvio
– Ei tuo kovin kuvaava käännös ole, mutta en ole vielä parempiinkaan ehdotuksiin törmännyt.

Item => ??
– Pitäisi ehdottomasti kääntää, mutta en ole löytänyt yhtään hyvää termiä tälle. Ehdotuksia?

Entity => kokonaisuus
– Jälleen ei kovin hyvä käännös, mutta paras tähänastisista. Kääntää tämä minusta ehdottomasti pitää. Entiteetti ei kerro tumpelokäyttäjälle yhtään mitään, kokonaisuus voi jälleen johdattaa oikeille jäljille.

Views => näkymät
– Normaalisti modulien nimet kannattaa nähdäkseni jättää kääntämättä, mutta tässä tapauksessa etenkin kasin osalta puhutaan enemmänkin asiasta kuin modulista, jolloin käsite kannattaa ehdottomasti kääntää kun kohtalaisen hyvä käännös löytyy.

Featuresin jättäisin kääntämättä, mutta ei sen kääntäminenkään väärin ole kun aika selkeästi kääntyvä sana on (jahka joku vielä keksii sen varsinaisen käännöksen – toiminnallisuudet on oma ei-kovin-hyvä ehdotukseni.)

kdiits commented

item - nimike
entity - entiteetti
token - symbolinen

tormu commented

Nimike on hyvä, Wikipediankin määritelmä täsmää - http://fi.wikipedia.org/wiki/Nimike

token ja symbolinen, downvote. Ei sillä, että keksisin sille mitään parempaa kuin pelkkä token. Aiemmin ehdotettu korjauskuviokin on tosin parempi kuin jättää koko token kääntämättä.

ArtoHeikinaro commented

Nyt mennään pieleen, että paikat raikuu. Viittaan alenpana olevaan kommenttiini.

Ei pidä kääntää vakiintuneita termejä kuten node tai URL. Ei auto sanastakaan tullut hyrysysyä vaikka sille semmoinen termi aikoinaan annettiin eikä kalossista upokasta.

Nyt menee tämä käännösvimma päin persettä suoraan sanottuna. Ei ole kahta eri lukijakuntaa kääntämisen näkökulmasta katsottuna. Ei ole Drupal osaajien porukka vastaan tavalliset suomalaiset.

Kun käännetään eli suomennetaan Drupal, niin se tehdään vain yhdelle porukalle eli niille jotka Drupalia käyttää. Ja koska suomen kieli on todella onneton teknisen termistön suhteen niin jätetään englanninkieliset termit node, URL, token yms. sellaisenaan elämään. Erillisellä lauseella voi sitten selittää termin olemuksen. Näin meille on vakiintunut mm. PC, läppäri, tabletti ja paljon muuta.

Siis rikastuttakaamme suomenkieltä ja silällyttäkäämme siihen uusia kansainvälisiä termejä. Mutta älkää perhana sentään tehkö itsestänne pellejä väkisinväännetyillä käännöksillä.

Arto Heikinaro
Mukana Drupalin syntyhetkistä lähtien, yli 40 alan suurinta Drupal Intranet/Extranet järjestelmää rakennettu kansainvälisille firmoille.

zeip commented

Pidetäänhän nyt kuitenkin keskustelu asiallisena, ei tässä ihan noin selvästi kukaan ”päin persettä” mene tai tee kenestäkään pelleä.

Asia ei ole ihan niin yksinkertainen, vaan tässä oikeasti on useampi kohderyhmä joiden tottumukset järjestelmän käyttämiseen erityisesti kielen osalta ovat ihan erilaiset. Ilmeisesti ensimmäinen kysymys joka pitäisi ratkaista on se, kenelle käännös ylipäätään halutaan kohdistaa – halutaanko se kohdistaa uusille käyttäjille jotka eivät ymmärrä alkuunkaan mistä järjestelmässä on kyse eivätkä välttämättä osaa englantiakaan lainkaan, vai halutaanko se kohdistaa tottuneemmille käyttäjille (joista todennäköisesti osa valitsee kielekseen kuitenkin englannin.)

Oma näkemykseni on, että käännös tulisi kohdistaa nimenomaan uusille käyttäjille jotka eivät englantia osaa, koska noille käyttäjille käännös on kaikkein kriittisin asia – se määrittää sen, onko järjestelmän käyttöön ylipäätään mahdollisuutta. Tehokäyttäjien osalta taas käyttäjät varmasti osaavat käyttää järjestelmää aika pitkälti riippumatta käännöksestä, joten suurin hyöty mielestäni saadaan nimenomaan huomioimalla ensisijaisesti nk. tumpelokäyttäjät.

Muita näkemyksiä?

aruuska commented

Kommentoinkin jo alemmas periaatteista. Kommentoin tähän vielä mielipiteeni noihin termeihin joita kyselit.

Alustusta:
Käännöstähän ei ikinä voi tehdä kunnolla ilman kokonaista lausetta / kontekstia jossa sana ja lause esiintyy, näin olen ymmärtänyt kun olen kääntämisen ammattilaisia kuunnellut, itse en ole ammattilainen. :)

Node, jätetään kääntämättä tai Sisältö (voisi olla, koska tätähän node melkein aina on käytännössä. "Add content" vie myös tällä hetkellä urliin node/add joten englanniksikin se on mielletty sisällöksi)
URL, ehdottomasti jätetään kääntämättä
Token, Korvattava kohta (yksi vaihtoehto viestiketjussa jo olevien lisäksi :)
Item, täysin riippuvainen kontekstista joten jätetään kääntämättä yksittäisenä sanana ja käännetään kontekstissa koko lause (perustan tämän huonon vaihtoehdon kääntämisen periaateesseen jota kannatan, joka on luettavissa alempana olevassa kommentissa)

Mielestäni erittäin idea hyvä jättää nimet ja verkko-osoitteet.

jhirn commented

Komppaan noden ja URL:n kääntämättä jättämistä. Samoin moduulien nimet ja verkko-osoitteet on mielestäni hyvä säilyttää alkuperäisinä.

Tokenin kohdalla kannatan korvauskuviota.

Entity on kyllä hankala. Taistelun jälkeen päädyimme entiteettiin. Sen osaa yhdistää englanninkieliseen termiin, eikä ole sen epäselvempi kuin "kokonaisuus". :)

Muutamia muita käännöshuomioita D7:n pohjalta:

Shortcut
D7 käyttää termeinä sekä pikalinkkejä että oikopolkuja. Onko tähän löydetty oikeaa vastausta?

Unpublish
Roisi ehdotus, mutta kävisikö lyhykäisyydessään "Piiloon"?

Provide a menu link
Näytä sivu valikossa

Parent item
Sijainti valikossa

Select media
Tässä olemme käyttäneet yleensä käyttäjälle helpommin avautuvaa "Valitse tiedosto" –käännöstä. Vastaavasti termien "Select media", "Remove media" ja "Edit media" kanssa.

aalamaki commented

Ok no tuo entiteetti näyttäisi voittavan ainakin tässä keskustelussa mutta jätän sen vielä nykyiselleen toistaiseksi, odotetaan vielä kommentteja sen osalle.

Päivitin käännökset tuon Parent item ja Select media osalta sekä Provide a menu link, nuo olivat parempia käännöksiä.

Shortcut sanan kohdalla sen kääntäminen riippuu kontekstista, kun puhutaan "shortcut" esimerkiksi linkkinä sisältöön, se kääntyy "oikopolku" kun taas esimerkiksi "Shortcut icon" kääntyy oikein "pikakuvake". Tsekkasin nuo läpi ja korjasin pari käännöstä.

Sellaiseen asiaan kommentteja, esimerkiksi kun käyttää admin menua niin olisiko parempi että siellä esim. "Views" olisi samalla nimellä myös suomenkielisessä käännöksessä eikä "Näkymät" kuten se nyt on? Sama juttu esimerkiksi "Features", kääntyy nykyisellään "Ominaisuudet".

Belham commented

Näkymät on ok sellaisenaan, Features käännös on mielestäni vähän omalaatuinen koska ominaisuudet on yleisesti käytössä oleva käännös sanalle settings, eikä muutenkaan kuvaa featuressia mitenkään päin. Kysymykseen tulisiko ne jättää kääntämättä niin vaikka henk. koht. minua ärsyttääkin suunnattomasti käyttää UIta jossa asiat on käännetty suomeksi on se sivustojen loppukäyttäjälle helpompaa ja mukavampaa kun kaikki on samalla kielellä. Eli näkymät ja ominaisuudet (kunnes tälle keksitään parempi termi) on mieletäni the way to go.

wroxbox commented

Ominaisuudet viittaavat settingsseihin, joten miten olisi esimimerkiksi paketti?

Belham commented

Ongelmana yhden sanan käännöksissä on taas kielen rajoittuneisuus. Miten olisi Toiminnallisuuspaketit?

ArtoHeikinaro commented

Huomaan, että väkisin yritetään kääntää suomeksi vakiintuneita englanninkielisiä termejä. Pieleen menee ja pahasti, kun näin toimitte. Annetaan tokeninkien, urlien ja muiden vastaavien termien säilyä.

Eikä ole muuten olemassa kahta erillistä ryhmää joita täytyisi kohdella erikseen käännöksissä. Drupal koodari ja perusjuntti eli täällä käsitelty tavallinen käyttäjä ovat sama asia kääntämisen suhteen.

Siis säilyttäkää perustermit englanninkielisinä ja jos token sanalle halutaan selvennystä niin sitten ihan oma lause selvennykseksi ja selitykseksi.

Muistakaa, että kalossi käännettiin eli sai suomenkielisen nimen upokas. Ja muistakaa, että suomennuslautakunta antoi autolle nimen hyrysysy ja kannusta tuli kaadin. Vaan kuka käyttää termejä upokas, hyrysysy tai kaadin. Lähdenpä hyrysysyllä töihin.

Vielä kerran, unohtakaa jo herran tähden englanninkielisten termien pakkokääntäminen suomen kieleen.

jhirn commented

Lyhyen toimistokierroksen tuloksena kannatettiin Viewsin säilyttämistä englanninkielisenä, koska on ikäänkuin erisnimi ja harvoin näkyy peruspäivittäjälle. Jos Features halutaan kääntää, kannatan termiä toiminnallisuuspaketit: Kuvaa käsittääkseni paremmin linkin takaa löytyvää sisältöä kuin kovin lavea "ominaisuudet".

kdiits commented

shortcut - pikakuvake
(pohjustus) main items - päänimikkeet
(villi ehdotus) parent item - kantanimike

kdiits commented

Provide a menu link - käytä valikkolinkitystä

tormu commented

Imho..

Shortcut
Sanoisin että oikopolku, ainakin mieluummin kuin Windows-maailmasta tuttu pikakuvake. Tässä tapauksessa yleensä on kyse tekstilinkistä eikä ikonista, johon sana kuvake mielestäni viittaa melko voimakkaasti.

Unpublish
Poista julkaisusta (vs Julkaise)

Parent item
Ylemmän tason kohta (kontekstiriippuvainen tosin. Jos menun yhteydessä pelkästään, niin sitten lähempänä tuota ehdotettua "Sijainti valikossa". Siinä silti ongelmana se, että ei valita sijaintia valikossa, vaan valitaan minkä kohdan alle item sijoitetaan)

Features
Toiminnallisuuspaketit on parempi kuin ominaisuudet.

Views
Näkymät, siis silloin kun kontekstina on se /admin/structure. Ei moduulin nimien käännöksiä. Vaikka devaajana mua sieppaa että se menukohta nyt ei oo siinä kohdassa aakkosellisesti tuotannossa kun on lokaalissa (Views vs. Näkymät), niin tuossa kontekstissa mielestäni puhutaan sellaisista asioista jotka myös ei-devaajan pitäisi ymmärtää. En väitä että epä-devaaja voisi conffata viewejä, mutta näkymät tuppaa vaan olemaan melko hyvä suomennos ;)

Ymmärrän ArtoHeikinaron tuskankin, mutta vain osittain. En lähtisi vertaamaan tabletin kääntämistä kosketustietokoneeksi tai sormilevyvekottimeksi ja esim. "featuren" kääntämistä toiminnallisuuspaketiksi. Feature sinällään ei ole mitenkään kieleemme yleisesti jämähtänyt nimitys it-piirien ulkopuolella, eikä sille ole mitään ongelmaa keksiä hyvää suomenkielistä vastinetta.
Komppaan siis sitä näkemystä, että käännetään ne kohdat mille löytyy parempi käännös kuin alkuperäinen termi. Näin ollen siis esim. node jätetään kääntämättä eikä mietitä väkisin jotain sanaa joka ei suoraan kerro mistä on kyse.

kari.kaariainen commented

Ruotsissa näitä on mietitty aika pitkälle, heidän toimintatavoistaan, millä ovat yhteisesti käännöksiä miettineet, voisi ottaa mallia.

https://localize.drupal.org/node/740

Muuten, ruotsiksi näkyy olevan käännetty node -> nod, äännettäneen "nuud". Ei siis knut, joka tarkoittaa solmua.

kdiits commented

node - noodi
Input format - formaatti

rade commented

Lyhyesti: Itse puhumme kehittäjien kesken mutta myös asiakkaiden kanssa "nodeista", ei solmuista.

aalamaki commented

Itsekin tuolla samalla kannalla eli tiputetaan se koko "solmu" pois ja jätetään kääntämättä, se vain sekoittaa asioita kun nodeista aina puhutaan.

Tuo "Input format", vierastan lainasanojen käyttöä, "syöttömuoto" on vakiintunut termi enkä oikein sitä lähtisi muuttamaan.

mikkopaltamaa commented

Useissa tämän sivun käännöksissä on mietitty käännöstä siltä pohjalta, että mikä olisi hyvä termi asialle, ei sen pohjalta, mikä olisi suora käännös Drupaliin valitusta termistä. Aiemman kokemuksen pohjalta sanoisin, että se ei kannata ja että lähes aina on parasta valita suora käännös.

Jos valitaan jokin muu termi kuin suora käännös, niin siitä saattaa seurata seuraavat ongelmat:

- Myös valittu termi tulee käyttöön englanniksi, jolloin sen kääntäminen vaikeutuu
- Englannin ja suomenkielisten termien yhdistäminen muuttuu vaikeaksi, varsinkin kehittäjille
- Valitut uudet termit eivät jää mieleen, jolloin ne eivät myöskään yleisty

Olen myös sitä mieltä, että huonoa termiä tai lausetta ei kannata yrittää korjata käännöksellä. Toisin sanottuna käyttöliittymän käännöksen ei minusta tarvitse olla yhtään sen parempi kuin alkuperäisen tekstin. Sen sijaan alkuperäisiä tekstejä kannattaa toki muuttaa ymmärrettävämmiksi ja helpommin käännettäviksi.

Eli tältä pohjalta kääntäisin keskustelussa mainitut Drupalin asiat mahdollisimman kirjaimellisesti.

Tässä ehdotuksia:

dashboard = kojelauta
display = näyttö
entity = entiteetti tai kokonaisuus (ei ole olemassa hyvää suomennosta)
feature = ominaisuus
input format = syöttömuoto
item = kohta/kohde (menu item = valikon kohta vs. no items = ei kohteita)
media = media
module = moduuli
node = noodi tai solmu (ei ole olemassa hyvää suomennosta)
parent item = yläkohta
provide a menu link = lisää valikon kohta (alkuperäinen teksti on huono)
select media = valitse media (alkuperäinen teksti on huono)
shortcut = oikopolku
shortcut icon = pikakuvake
sub item = alakohta
taxonomy = taksonomia/luokittelu
token = tokeni tai korvauskuvio (ei ole olemassa hyvää suomennosta)
URL = URL (ei tarvetta kääntää teknistä lyhennettä)
unpublish = poista julkaisu
view = näkymä
web address = verkko-osoite

Useampi henkilö kommentoi sitä, tarvitseeko tiettyjä termejä kääntää ollenkaan. Yleisesti ottaen kyllä, mikäli järkevä käännös on olemassa.

Kääntämisessä on ideana kääntää kielestä toiseen ja jos joitain asioita ei haluta kääntää siksi, että kehittäjät ovat tottuneet englanninkieliseen termiin, niin mihin vedetään raja? Jos puolet sanoista on suomennettu ja puolet ei, niin lopputulos on sekava ja hankala lukea.

Englantia preferoiva voi toki käyttää järjestelmää englanniksi ja puhua asioista englanniksi, oli käännös suomeksi olemassa tai ei.

aalamaki commented

"Kääntämisessä on ideana kääntää kielestä toiseen ja jos joitain asioita ei haluta kääntää siksi, että kehittäjät ovat tottuneet englanninkieliseen termiin, niin mihin vedetään raja? Jos puolet sanoista on suomennettu ja puolet ei, niin lopputulos on sekava ja hankala lukea."

Juuri tuon takia olen pyrkinyt kaikki mahdolliset termit kääntämään ettei siellä näy englantia tai lainasanoja. Tuo "node" on minusta kyllä edelleenkin sellainen että koska sille ei ole kunnollista suomennosta, antaisin sen olla "node".

Tuo "Valitse media" on tavallaan kuvaavampi kuin "Valitse tiedosto" joka käännöksissä nykyisellään on käytössä koska mediallahan voidaan viitata muuhunkin kuin tiedostoon; esimerkiksi youtube videoon.

aruuska commented

Kääntämisen periaatteista olen samaa mieltä mikkopaltamaa:n kanssa että "Yleisesti ottaen kyllä, mikäli järkevä käännös on olemassa." Järkevän käännöksen määrittely on vain melkoisen hankalaa.

Olen itse sen kannalla että koska suurin osa Drupalista on käännettävissä "helposti" suomenkieleen, jätetään hankalat kääntämättä. Tässä komppaan ArtoHeikinaro:a ja muutamaa muuta siksi että ns. pakkokääntämistä ei tapahtuisi. Eli jos jokin termi ei oikein ota kääntyäkseen "järkevästi" niin se jätetään kääntämättä. Itse lisäisin näissä tapauksissa selitteitä käyttäjille. Mieluummin siis jätetään kääntämättä kuin että keksitään vain jokin suomenkielen termi vastaamaan englannin termiä. Jatkossa käännöksiä voidaan kuitenkin aina lisätä.

On toki tämän lisäksi olemassa varmasti jonkin verran termejä joihin on olemassa useampi "järkevä" vaihtoehto. Silloin kyseessä on mielestäni enemmänkin mielipide asia, jolloin en näe ongelmaa että joku "järkevistä" vaihtoehdoista vaan valitaan käännökseksi.

turpeine commented

Suosittelisin entiteettiä ja solmua.

classification = luokittelu, eli ehkä tuo taxonomy voisi olla taksonomia.

Lyhenteitä ei tosiaan pidä kääntää, eli esim. URL on URL, tarvittaessa URL-osoite.

Tosiaan sen olen huomannut, että aika moni haluaa väkisin vääntää yksisanaiset englannin kieliset sanat suomeksi myös yhdellä sanalla. Olisi hyvä pohtia myös voiko sen kertoa esim. kahdella sanalla.

token = korvauskuvio? Kuulostaa jotenkin hassulta. Mitä jos se olisi esim. korvausteksti / korvattava teksti / täytesana?

aalamaki commented

Entity korvattu, "kokonaisuus" kuopattu. Asiasta vaikutti täällä vallitsevan consensus joten Entity on nykyään entiteetti. Vierastan kyllä edelleenkin vierassanojen käyttöä, se ei kuulu suomenkieleen vaan tuolloin jos ei ole kunnollista käännöstä, pitäisi jättää kokonaan kääntämättä. Tuossa nyt esimmäinen varsinainen iso korjaus joka tapauksessa.

Hyvä että keskustelua saatiin aikaan, ehdotuksia tulikin ihan reilusti mikä hyvä juttu joten jatketaan keskustelua. Homman tehostamiseksi voisi myös itse käydä lisäilemässä käännösehdotuksia tuonne l.do.o:hon. Tuossa on kuitenkin tullut tehtyä niin paljon käännöksiä että siellä on ihan varmasti käännösvirheitä eikä itselläni aika riitä kaikkien läpikäyntiin, yhteisellä panoksella saadaan hommaa tehostettua :)

Niille jotka eivät ole ennen tehneet, käännösten importointi ei tällä hetkellä toimi mutta ehdotuksia voi lisätä tuonne "Translate" tabin alle l.d.o:ssa, ne menee sieltä hyväksyttäviksi ja päivitetään kun joku ne on hyväksynyt.

zeip commented

Tämä Localize-sivuston sivuominaisuus on melko kehno tapa näiden termien koostamiseen ja niistä keskusteluun. Ehdottaisinkin, että lähdetään kokoamaan termejä Kotoistuswikiin (http://wiki.lokalisointi.org/), joka on erikseen tätä varten tarkoitettu ja josta saadaan myös muiden ohjelmistojen kääntäjien näkemyksiä tarvittaessa. Sopiiko tällainen menettely?

kari.kaariainen commented

Sisältösivu olisi aika hyvä noden käännös. Kotisivukone käyttää sitä, erotuksena komponenttisivuista, joita Drupalissa vastaisivat näkymät yms.

zeip commented

Sisältösivu olisi tosiaan käyttökelpoinen käännös, jos nodet olisivat varsinaisesit pelkästään sisältösivuja. Ne kuitenkin tuppaavat olemaan vähän muutakin: Monesti tulee esimerkiksi tehtyä jokaisesta henkilöstä tai FAQ-kysymyksestä oma nodensa, jolloin yksi node ei välttämättä koskaan edes näy irrallisena vaan ainoastaan näkymässä – jolloin sivuna varsinaisesti toimiikin tällainen komponenttisivu.

Solmu-käännös on myös ainakin Drupal-maailmassa jo melko vakiintunut, ja vaikka se konseptina onkin haastava ymmärtää niin sen vaihtamisesta tulee käytännössä aika paljon haittaa – käännösmateriaalissa se mainitaan varmasti lukemattomissa kohdissa, ja samoin kaikenlaisissa ohjeteksteissä. Toisaalta olisi varmasti myös syytä pitää käännös sellaisessa kunnossa että jos joku päivittää olemassaolevan, jo käyttäjille koulutetun sivuston käännökset uusimpiin saatavilla oleviin niin käyttäjillä ei silti ole suuria vaikeuksia käyttää sivustoa.

onaz commented

Valitettavasti mitään sivu-alkuista ei voi nodelle käyttää, koska se voi tosiaan olla tapahtuma, henkilö, nosto(sisältö) tai vaikka mitä. "Sisältöyksikkö" voisi olla ns. toimiva käännös, mutta … ei todellakaan ole. Solmulla mennään.

lauriii commented

Olen samaa mieltä että node != sivu. Mielestäni solmu käännös on ihan hyvä, ongelmia tämän kääntäminen kuitenkin saattaa aiheuttaa jos joku yrittää käyttää Views UI:ta suomen kielellä. Siellä solmun mieltäminen nodeksi relaatioissa jne. on huomattavasti hankalampaa kuin muualla. Voi olla että ei ole pelkän solmu käännöksen luoma ongelma tosin.