Swedish translation of Drupal 5

Jag har inte tidigare engagerat mig i översättningen, men i dag installerade jag 5.0-rc1, importerade översättningen för 4.7.x. När drupal sa att 2176 av 2363 strängar redan var översatta tänkte jag att de återstående 187 skulle kunna fixas rätt snabbt. Sedan började jag titta lite på alla fuzzy entries och insåg snabbt att det är ett rätt stort jobb. Dessutom stötte jag på en del gamla översättningar som var felaktiga eller i alla fall inte helt konsistenta. Lite exempel:

"locale" -> "internationellt", "språkhantering" eller "anpassning".
Att ha flera olika översättningar av samma sak är lite förvirrande. Locale betyder ju egentligen mer än översättning, men i drupal hanteras ju andra saker (som datumformat) på annat sätt, så ordet "språk" är nog det bästa i det här sammanhanget.

"Clean URLs" -> "Snygga webbadresser eller "snygga URLer".
Att använda URLer och webbadresser omväxlande är lite förvirrande. Dessutom vet jag inte om "snygg" är rätt ord att använda i sammanhanget. Rakt översatt borde det bli "rena webbadresser" och ser man lite till den bakomliggande anledningen till den här finessen, så kanske ord som sökvänliga eller sökmotorvänliga är bättre val. En vanligt engelsk term i det här sammanhanger är SEO (Search Engine Optimization) och det säger en del om vad det handlar om, nämligt att google inte ger lika höga poäng när det ingår ett likhetstecken i adressen.

"anonymous" -> "anonym", "ej registrerad användare", "som inte är inloggad med kontot" eller "icke inloggade användare"
Kärt barn har många namn. Anonym är ett svenskt ord som borde kunna användas genomgående.

"Sidebar" -> "sidfält" eller "sidofält".
Borde synkas. README.TXT i cvs säger "sidofält", men "sidfält" är nog mera normal svenska.

"Submitted by" -> "inskrivet av"
Borde räcka med "skrivet av". "Inskrivet" låter lite väl mycket som kanslisvenska.

"legacy" -> "arv"
Den här översättningen är ett typiskt exempel på när man måste byta till det engelska gränssnittet för att förstå vad som avses. Legacy betyder i princip aldrig arv i datorsammanhang. Den här modulen borde heta nåt som antyder vad det är, nämligen stöd för gamla versioner.

"legacy handlers" -> "arvshanterare"
Kan det vara advokater som avses?

Det här var bara några exempel. Jag har bara tagit en snabbtitt, så det finns säkert många andra ställen där det kunde bli bättre.

En annan sak att fundera över om namnen på färgscheman i garland/minelli ska översättas, eller betraktas som namn. "Kall dag" och "grönstråle" blir kanske lite krystat?

Målet med översättningen måste rimligtvis vara att göra det lättare för mindre datorkunniga användare, och när man behöver titta i po-filerna för att förstå vad som avses kan man nog inte riktigt säga att det målet är uppnått. Själv kör jag (tyvärr?) för det mesta engelska användargränssnitt i de flesta programvaror eftersom många översättningar inte är helt att lita på, eller utelämnar delar av informationen.

Hoppas ingen tar de här synpunkterna som någon personlig kritik, det är absolut inte meningen. Jag inser att ni har lagt ned mycket tid på översättningen, och har full förståelse för att översättningar är ett jättejobb eftersom man inte bara kan titta på lösryckta strängar, utan måste kolla källkoden och provköra alla moduler för att få en känsla för vad som är rätt i varje fall. Men alla förbättringar som kan göras är ju i alla fall ett steg i riktning mot den perfekta översättningen (om den finns). Att uppdatera och utöka README.TXT och publicera den på projektsidan är nog ett bra sätt att få en lite mer koordinerad översättning.

Själv funderar jag på om jag har tid att ta någon mer aktiv del i översättningen, men de här kommentarena är i alla fall ett litet bidrag till en översättning som redan är ok, men kan bli bättre.

Ok, jag tar på mig att göra en snabb första uppdatering av README.TXT. Det blir en del tillägg och en del ändringar. Till exempel borde "delete" vara "radera" och inte "ta bort". (Det senare är mera motsvarigheten till "remove".)

Sedan måste det rimligtvis vara ett levande dokument som uppdateras i takt med diskussionen här. Alltså: varje gång någon klurig översättningsfråga får sin lösning borde projektledaren se till att den läggas in i filen.

Förutom README.TXT ger jag mig på följande filer:

user-module.po
system-module.po
node-module.po
general.po

Sen vet jag inte hur policyn är för releaser, men jag tycker i alla fall att man borde lägga ut en dev-version så fort som möjligt. Vi pratar ju trots allt om 5.0-rc1, inte någon beta utan en release candidate, alltså en i princip färdig version som folk givetvis vill börja prova så fort som möjligt. Den polska och tyska översättningen som redan finns tillgängliga för nedladdning verkar inte heller vara färdiga.

Många fuzzy entries verkar också vara så enkla att de bara handlar om att det handlar om att ändra till stor (versal) begynnelsebokstav. Men på vissa ställen får man verkligen hålla koll, för ibland undrar man nästan hur algoritmerna fungerar. Vad sägs till exempel om att "User settings" har blivit "E-postinställningar för användare". Lite väl "fuzzy" i mitt tycke.

Jag är en bra bit på vägen med user-module.po. Har börjar med att gå igenom alla vita entries (ja, jag änvänder poedit). Förvånande att det finns rena skrivfel i del gamla översättningarna. Har dessutom hittat en del skräckexempel på sär skrivning, vad sägs till exempel om "Användar registrerings inställningar". Ett exempel på skräckord som har dykt upp på några ställen är "notifiering". Jag noterarar frenetiskt i README.TXT hela tiden. Eftersom jag har valt ut några rätt allmänna moduler så tror jag att README.TXT ska vara rätt bra uppdaterad när jag har tagit mig igenom mina filer.

Verkar i alla fall inte bli några sysselsättningsproblem den här julen...

Hej,

Jag kan ta mig an ett par filer för översättning. Vore det bäst att avvakta tills perf har gjort sin första genomgång och uppdaterat readme.txt? Håller vi därefter en generell diskussion om eventuella ordval utifrån readme.txt eller är det bara att tuta och köra och slänga upp frågor allt eftersom de dyker upp? Jag började titta på några av de mindre i tron att man snabbt kunde markera dom som klara. Naturligtvis dök det upp några ord som jag är osäker på bästa översättningen av. T.ex.

• locale
• legacy
• cron

...för att nämna några. Jag har så här långt varit inne och ändrat lite i följande filer så det är väl lika bra att tjinga dom.

• locale-inc.po
• file-inc.po
• color-module.po
• theme-inc.po
• common-inc.po

Pontus

Jag jobbar för fullt på REAMDE-filen, som blir README.html i stället för README.TXT. Det blir en helt fristående fil med enkel layout och inbäddad css. Dessutom $Id$ i sidfoten för RCS/CVS. Hade tänkt fylla på den efterhand som jag tar hand om mina moduler, men eftersom arbetet verkar ha tagit fart nu är det väl lika bra att ladda upp en preliminär version så fort som möjligt. När jag har laddat upp den bör den givetvis versionshanteras i CVS, så det blir nog enklast att någon med skrivrättigheter i CVS tar på sig att uppdatera filen i takt med diskussionerna här. (Gissar att det blir en del snabba ändringar eftersom en del av mina förslag säkert blir nedröstade.)

Så några synpunkter på de aktuella orden:

• locale - språkanpassning tycker jag blir bra eftersom Drupal inte använder något annat ur localebegreppet (tid, valuta, sorteringsordning etc). Att det blir samma som i 4.7 är dessutom inte helt fel.
• legacy - svårt ord, men bakåtkompatibilitet är väl inte helt fel. Eftersom modulnamnen inte översätts ser ju dessutom adminstratören det engelska ordet, och då bör man väl fatta vad det handlar om (adminstratörer är ju ofta mer datorkunniga, särskilt om de behöver stöd för gamla moduler). Vad jag kan se används inte ordet för vanliga användare.
• cron - som benämning på unixprogrammet ska det givetvis inte översättas. Om det används för att beskriva fenomenet som sådant så kanske någon med svensk windows kan kolla vad "scheduled tasks" heter där. (Själv kör jag engelsk linux, så jag är inte till mycket hjälp på den här punkten.)

Här kommer en uppdaterad README. Koden validerar som xhtml 1.1. Egentligen har jag som princip att köra application/xhtml+xml, men det kräver content negotiation eftersom IE6 inte vet vad xml är. Indentering av ul-listorna blir också lite konstig i IE6. Det ser dock rätt ut i sjuan, så det får vara så. Windows update lär väl lösa det problemet inom kort. Givetvis är det innehållet som är det viktigaste, men jag gissar att det dräller av webdesigners samt html- och phpprogrammerare här, så det är väl lika bra att nämna lite om teknikaliteterna.

I den händelse att jag skulle ha klantat till det med bilagan så finns filen finns även tillgänglig på http://www.foreby.se/README.html.

Har lagt till lite mer och bifogar ny version. (Min websida är också uppdaterad). Jag kan hålla listan uppdaterad under de inledande diskussionerna, men som jag sa tidigare är det nog bättre att någon med skrivrättigheter i CVS tar över efter det.

Så lite kommentarer:

• access - jag menar inte behöriget i det här fallet utan till exempel "deny access". Eftersom jag redan har tagit med det exemplet i ordlistan så har jag tagit bort "access" som ensamt ord.
• tråd - jag tror att det är det bästa ordet, och som du säger är det rätt etablerat. Korrespondensvy passar nog bättre i e-postsammanhang, men jag tog med den kommentaren som diskussionsunderlag.
• Jag har inte tagit bort några gamla ord eftersom jag tänkte att det fanns en anledning till att de hade kommit med i listan. Men det kanske bara är det tyska arvet som spökar; kanske de här orden inte hade lika uppenbara översättningar på tyska. Vissa av de uppräknade orden tror jag dock att man ska ha kvar, annars kan kanske article bli inlägg och image kan bli figur.

Observera också att jag har ändrat den gamla översättningen på ett par ställen (alla var inte med i ordlistan). Det kanske inte är helt okontroversiellt, och det kan finnas en poäng i att behålla den gamla översättningen så att folk känner igen sig:

• delete - ta bort har blivit radera.
• reset - om lösenord. Nollställa har blivit återställa.
• attribute - attribuera har blivit tillskriva.
• administer, manage - båda har blivit hantera.
• anonymous user - har blivit gäst (fanns ett antal översättningar tidigare).
• authenticated - autentiserad (hette ibland inloggad tidigare). Det är är ett grundbegrepp så här måste vi vara överens.
• samt några till som har negativa kommentarer i README (inte xxx).

En annan sak som jag har ändrat i user-module.po är att "@module module" har blivit "modulen @module" i stället för det (i mitt tycke) osvenska "@module modul".

Jag får det dock inte att bita i drop-downlistan på /admin/user/user (visa bara användare där rättighet är...). I den listan är det fortfarande engelska överallt, trots att rättigheterna är översatta om man tittar på /admin/user/access. Jag har inte grävt så djupt i php-koden ännu så jag vet inte om det saknas en t(), men lite skumt är det i alla fall.

Kommenterar mig själv: Om autentiserad känns lite för tungt kan man helt enkelt kalla den kategoring för "registrerade användare". Alltså gäster och registrerade användare (anonymous and authenticated users).

Kommenterar mig själv: Om autentiserad känns lite för tungt kan man helt enkelt kalla den kategorin för "registrerade användare". Alltså gäster och registrerade användare (anonymous and authenticated users).

Jag tar även profile-module.po. Det är en väldigt liten modul, och den hänger ihop med user-module som jag håller på med just nu.

Kommentar till min egen kommentar till mig själv: Jag har tittat på SMF (forumprogramvara) och där skiljer man på gäster och användare. Det är nog den vägen vi ska gå, men förmodligen med tillägget "registrerade" för att vara lite tydligare.

Jag tycker instruktionerna i readme.txt är glasklara. Bra jobbat perf.

Det finns en del ord jag skulle vilja kommentera.

Printer-friendly, nuvarande översättning skrivarvänlig (utskriftsvänlig) skulle vilja föreslå utskriftsversion istället med utskriftsvänlig som 2:a alternativ. Det är ju en anpassad sida som presenteras för att ge användaren en mer lättläst utskrift och inte underlätta arbetet för skrivaren (skrivarvänlig).

block, nuvarade översättning är block men borde det inte även vara blockera?

RDF feed och RSS feed borde väl vara RDF-flöde respektive RSS-flöde för konsekvens med bl.a. news feed = nyhetsflöde.

unblock - blir det inte bättre svenska med "häv blockering"? (Kunde inte hitta ordet avblockera i NE)

Jag upplever användningen av orden authenticate, authorize, permission och access i den gamla översättningen som lite godtyckliga. Det kan bero på hur man själv värderar orden och hur den ursprungliga författaren har tänkt. Jag var inne på wikipedia för att få fram en beskrivande engelsk text som kunde översättas och eventuellt fungera som vägledning.

The system authenticates the user through log-in. The authorization to use a resource is determined by a users permissions which are defined by access rules.

Systemet verifierar (authenticates) användaren via inloggning. Behörighet (authorization) att använda en resurs bestäms utifrån användarens tillstånd (permission) vilka är definierade av åtkomstregler (access rules).

Cron må vara ett program men det är geek-speak i mitt tycke. Det finns nog ingen som direkt förstår vad det innebär och vi sa väl att vi skulle tänka på användarna. :) Scheduled tasks blir rätt och slätt schemalagda aktiviteter så det får bli mitt och windows' förslag.

Slutligen har vi orden parent, child, sibling och orphan vilka med engelska och t.ex. javascript som bakgrund känns hur logiska som helst. Just nu ser det ut som följer:

parent = ovanliggande
child = underliggande
sibling = syskon, på samma nivå - skulle kanske vara intillliggande men bäst är nog "på samma nivå"
orphan = föräldralös, lös - okopplad eller något liknande skulle kunna vara bättre. Föräldrakopplingen verkar lite fuzzy.

Pontus

Utskriftsversion blir utmärkt. Har lagt in det i REAMDE.

Block kan vara två saker, dels ett block med information i sidfälten, dels att blockera. Kanske det senare ska heta spärra i stället? Låter det vara blockera till vidare och har även ändrat avblockera till häv blockering. Om vi byter till spärra, vad heter då det negerade uttrycket?

Jag har även ändrat strömmarna till flöden. Håller fullständigt med på den här punkten. Anledningen till att jag inte redan hade ändrat det är att jag försöker ha lite respekt för hur tidigare översättare har resonerat.

Cron: det finns faktiskt inga hänvisningar till unixprogrammet, de finns bara i handboken. Har lagt till ordet som schemalagda händelser. Att det heter så i windows är ett tungt argument.

Authenticate: ska kanske helt enkelt bli verifiera?

Authorization: här verkar vi vara överens.

Permission: tycker att rättighet är det bästa ordet.

Access: får väl bli åtkomst när det handlar om reglerna för att spärra användare. Det används dock även som "access to" och i det fallet borde det vara "tillgång till". Sedan har vi "access control" som leder till en sida där man ställer in åtkomst/rättigheter för alla moduler.

Det här är lite av en soppa, och det verkar inte som om den engelska versionen är helt konsekvent. Om "access rules" ska bli åtkomstregler (spärrarna), vad blir då "access control"?

För sibling räcker säkert "på sama nivå". Orphan är den svåraste av de fyra. I typografiska sammanhang heter en ensam rad längt ned på en sida "widow" och längst upp "orphan". De svenska fackuttrycken är änka och horunge, men det kanske inte är så lämpligt i det här fallet. Eftersom vi är i webbsammanhang så kanske "olänkad" är ett bra ord?

Bifogar uppdaterad version av README.html.

Jag ser det inte som att trampa på någons tår dessutom har ju Drupal en tradition i att skrota gammalt för utvecklingens skull. Det är ju också tack vare de tidigare översättarnas arbete som vi nu har möjlighet att finlira lite.

Permissions = rättigheter Här är vi inte överens. Rättigheter känns lite starkt i mina öron men jag skyller det på mina 10p juridik. Rättigheter ser jag som något orubligt som t.ex. rösträtt, yttrandefrihet och demonstrationsrätt (som dock kräver tillstånd att hålla). Tillstånd är något man ansöker om och beviljas t.ex. körkortstillstånd, utskänkningstillstånd och skriva inlägg. Men vi kan låta det stå som rättigheter tillsvidare.

Orphan = olänkad. Det låter inte helt fel.

Access?!? Helt klart för många kockar till den soppan. Hela menystrukturen verkar lite knepig vid närmare granskning. Jag sover på saken och hoppas på någon snilleblixt. Får väl lämna något till er att fundera över. Om vi behåller översättningen rättigheter (permissions) så skulle access control kunna bli användarrättigheter.

Övriga punkter känns bra.

Sorry, skrev lite fel nyss. "Schemalagda aktivitetet" skulle det givetvis vara.

Clean URL tycker jag vi översätter med "rena webbadreser".

Vad ska förresten override heta? Den nuvarande översättningen är åsidosätta (man tillåts åsidosätta en inställning om man har vissa privillegier.) Det här är i enligthet med datatermgruppen, men Jag tycker att det låter otroligt stelbent, men det finns kanske inget bättre.

Slutligen (efter att ha jobbat lite mer med general.po) tror jag att vi helt enkelt ska prata om gäster och användare.

1 OK
2 OK
3 override = ta över
Det känns som det skulle passa in i general.po sammanhanget i alla fall. Snabbsökning gav denna läsvärda artikel om override och översättningar generellt. ->http://computersweden.idg.se/2.139/1.17882
4 Inga fler reloads innan jag stänger datorn. Funderar på gästerna imorgon.

@perf Är det gäster respektive användare som är problemet eller är det några specifika översättningar? Kan du i så fall tala om var man kan titta på dom?

Hjälp sökes till search-module.po (vilken jag paxar nu).

poEdit har följande sträng att översätta:

The search engine works by maintaining an index of the words in your site's content. You can adjust the settings below to tweak the indexing behaviour. Note that the search requires cron to be set up correctly.

search.module innehåller följande sträng där <p> taggarna i t() gör att den inte matchar ovanstående sträng:

      return t('
<p>The search engine works by maintaining an index of the words in your site\'s content. You can adjust the settings below to tweak the indexing behaviour. Note that the search requires cron to be set up correctly.</p>
');

Det är första gången jag använder poEdit så jag kanske missar något men jag kunde inte ändra den engelska strängen i poEdit och lägga till <p>-taggarna däremot gick det bra att ändra i search.module men det skall väl ändå inte vara nödvändigt???

Glöm mitt senaste inlägg. Jag hade loggat in på en beta2 version jag fortfarande pular med. Det fungerar som det ska i RC1.

Angående gäster och användare: Problemet är att det är lite spretigt i den gamla översättningen. Det pratas om gäster, besökare och anonyma användare, ej registrerade användare, icke inloggade användare etc. Även de som är registrerade har flera olika översättningar.

På engelska använder man också flera olika uttryck, men kan den svenska översättningen bli tydligare än originalet är det väl inte fel.

Så frågan är alltså om ni tycker att det är ok att kalla de två kategorierna för "gäst" respektive "användare". Så beskrivs de redan i 4.7 i den korta ordlistan, så det borde vara välkända begrepp som man borde använda genomgående.

En sak till: vad kallar vi "online"?

Först webbplatsens status när det gäller underhåll (maintenance). Där heter det idag uppkopplad och nedkopplad, helt enligt datatermgruppens rekommendationer.

Sedan används det även i en annan betydelse, till exempel i rubriken "Who's online?". I den nuvarande översättningen heter det "Vilka är inloggade", vilket är lite missvisande eftersom man även räknar upp antalet gäster. Den rekommenderade översättningen är "ansluten", men man kan enligt datatermgruppen även använda "online" på svenska (om man absolut måste). Just i det här sammanhanget lutar jag åt "Vilka är aktiva".

En tredje användning är när det pratas om att handboken är tillgänlig online. Med samma betydelse har "online help" i 4.7 översatts till "hjälp online". I den här betydelsen borde man kanske använda något annat ord?

Kan tilläggas att det engelska orignalet (i vanlig ordning?) inte är helt konsekvent, utan använder "online" både i betydelsen inloggade användare, och besökare i allmänhet.

Uppkopplad/nedkopplad låter bra.
Vilka är aktiva likaså.
online help - här kar jag också stött på patrull. Det fanns dock inget online med men de pekade mot drupal.org. En variant jag skulle kunna tänka mig är följande där den feta texten är mitt tillägg och länktexten förblir oöversatt.
Mer information finns i anpassnings- och konfigurationshandboken (extern resurs på engelska) Search Page.

Jag har ännu inga konkreta förslag på ditt förra inlägg om gäster/användare. Jag får fundera lite till.

Även om man anpassar länken så måste i alla fall själva uttrycket översättas. Det finns till exempel på huvudhjälpsidan: "Referenshandboken som finns online...".

När det gäller länkarna till handboken, tycker jag att det blir lite konstigt med blandningen av svenska och engelska. Jag skulle kunna tänka mig att skriva så här:

Läs mer om sökning i konfigurations- och anpassningshandboken.

Eventeullt kan man lägga till din parentes på slutet, men jag tycker nog inte att den är nödvändig. Ska man ha med den ska det nog inskränka sig till att stå "(engelska)". Att kalla länkar till Drupals egna websidor för en extern resurs skapar nog bara förvirring. Sidorna är ju tänkta som en naturlig förlängning av hjälpsystemet.

Mitt förslag på menystrukur för administration ser ut så här:

• Administrera
  • Byggstenar
  • Innehåll
  • Konfiguration
  • Användare
  • Loggar
  • Hjälp

I mitt tycke en rätt klar uppdelning, förutom "konfiguration" eftersom allting egentligen är konfiguration. Men det är ju inte klarare på engelska.

Det är mera i löpande text som jag menar att både administer och manage borde kunna ersättas av hantera, men det är inte så viktigt. Det är ju inte precis så att någon blir förvirrad av de här orden.

Jag tror att vi kan vara överens om gäster och användare, med förtydligandet registrerad använare eller inloggad användare på vissa ställen.

Jag tycker också att "spärra" är bättre än blockera.

Jag hittar inget ställe i koden där man refererar till unixprogrammet cron. Den kopplingen verkar bara finnas i handboken.

Om vi kan enas om "Läs mer om xxx i konfigurations- och anpassningshandboken" är det bra om vi kan vara konsekventa. Den här strängen finns i alla moduler, så det är inte så enkelt att en person ser till att det blir rätt, utan var och en måste tänka på det här. Frågan är också vad "xxx" ska vara. I mitt exempel med "sökning" var det lätt att hitta ett ord, men hur gör man med moduler som system eller node? Mitt uppdaterade förslag är att skriva "Läs mer om modulen xxx i ...", där xxx alltså är det oöversatta namnet på modulen. Det är blir väldigt konsekvent eftersom den här texten bara förekommer i samband med modulerna, och precis ovanför en rubrik som heter "Adminstrationssidor för modulen xxx" (enligt mitt förslag).

Några småproblem:

Rollnamn översätts inte. Det betyder att de fördefinierade rollerna "anonymous user" och "authenticated user" heter så även med svenskt användargränssnitt. De synsunder /admin/user/access och /admin/user/roles. Det är väl inte mycket annat att göra är att skriva det svenska namnet inom parentes efter det engelska i den inledande hjälptexten på /admin/user/roles.

På /admin/user/user kan man filtrera användare efter tre kriterier. Den andra listan ("show only users where permission is...") är alltid på engelska, även om samma strängar blir på svenska under /admin/user/access. Listan under ("show only users where status is") blir dock översatt. Kan någon verifiera att det här är en drupalbug och inte bara ett problem med min installation.

Jag tar även common-inc.po.

Har hittat en bugg i common-inc.po. Alla placeholders för datum och tid (år, veckor, dagar, timmar, minuter, sekunder) står som %count i po-filen, men i includes/common.inc hänvisas bara till @count. Jag har uppdaterat i min kopia och verifierat att det löste problemet med pluralisformerna som inte översattes, och har slängt iväg en buggrapport.

Ny README, uppdaterad enligt den senaste diskussionerna.

Här är ett litet tips till unixanvändare för att undvika onödiga stavfel i po-filerna: Använd gtranslator i stället för poedit, eller i alla fall som ett extra verktyg. I gtranslator kan man göra stavningskontroll. Kräver att man har installerat aspell med svensk ordlista, och skriver in följande i ~/.aspell.conf.

lang sv_SE

Jag missade att common-inc.po redan var tagen, så Thor-X får givetvis fortsätta med den. Se dock min kommentar om placeholders som behöver ändras även i den engelska texten.

Mer till Thor-X (som håller på med theme-inc.po): Du har väl redan hittat det, men om inte så finns det en rejäl felöversättning från den gamla versionen där "syndicate content" har blivit "prenumerera på innehåll", vilket är motsatsen till vad det borde vara (dela ut/publicera eller nåt sånt). Stängen är inte ens fuzzy.

Jag har förresten ett förslag så att inte fler klantar sig som jag och ger sig på dubbelarbete: På projektsidan skulle det kunna finnas en tabell över alla modulerna där det framgår vem som har paxat vilken.

Title:
rubrik är utmärkt.

body:
Menar man brödtexten förutom ingressen kanske brödtext är ett bra ord, men annars tycker jag att "hela texten" är bra. Det har jag använt i systemmodulen för inställningar för RSS (rubrik/ingress/hela texten) för (title/teaser/full-text).

story:
Artikel tycker jag räcker. Det är inte alltid det handlar om nyheter.

machine-readable:
maskinläsbar är väl ett vedertaget svenskt ord. Datorinriktad tycker jag är lite för vagt. Typiskt ett ord som kan få en att byta språk för att förstå vad som egentligen avses.

human-readable:
När det gäller användarinriktad har jag samma invändning som ovan. Svenska grenen av translation project använder enbart "läsbar" när det gäller optionen -h till ls, du, df med flera. Grundproblemet är nog att den engelska termen inte är särskilt bra. Till exempel pratar man i path-module.po om human-readable i samband med alias, som om /node/123 inte skulle vara läsbart. I det fallet tycker jag enkel eller användarvänlig är rätt ord. I de aktuella exemplen i content-types.po kanske "synlig" är ett bra ord.

Generellt behöver man nog inte hänga upp sig på att ha en entydig översättning av den här typen av ord. Det är inget grundläggande begrepp i drupal och förekommer bara på något enstaka ställe, och då i olika sammanhang.

Jag tar förresten även path-module.po.

När det gäller mitt förslag om en lista på upptagna filer så förutsatte jag att det fanna någon som hade editeringsbehörighet på en lämplig sida, men om så inte är fallet så faller ju förstås förslaget.

En wiki hade givetvis varit bra, och eftersom jag ändå skulle titta lite på senaste versionen av dokuwiki så har jag slängt upp en installation på http://www.foreby.se/drupal-sv. Så om den duger är den frågan avklarad. Annars skulle jag som sagt ändå göra jobbet. (Wikin är på engelska eftersom den svenska översättningen milt uttryckt lämnar en del att önska.)

Jag ska förövrigt snart börja ladda upp mina moduler. Har bara lite stavningskontroll kvar, sen ska det dyka upp en gäng filer.

Här kommer den första versionen av följande filer:

profile-module.po
user-module.po
system-module.po
node-module.po
general.po
path-module.po

Nu ger jag mig på forum-module.po

Har en fråga angående forummodulen. Den nuvarande översättningen använder "fora" som pluralis av "forum", men jag tycker att den gamla latinska pluralformen känns mossig. I moderna ordböcker står den som andraalternativ och det känns för mig som en tydlig markering. Till och med byråkrater som är glada i att slänga sig med uttryck som folk inte förstår tycker att det ska heta forum i pluralis (http://www.regeringen.se/sb/d/2729).

En fråga till: ska vi verkligen översätta namnen på modulerna? Det blir lätt lite förvirrande om man läser om kommentarmodulen i löpande text, men sedan hittar den som "Comment" i hjälpen och vid aktivering av modulerna. Borde man kanske skriva "modulen Comment" i stället (med versal så att det lite tydligare framgår att det tolkas som ett namn)? Exempel från modulen Forum/forummodulen:

Forummodulen kräver att Taxonomi- och Kommentarmodulerna module är aktiverade.

Observera att de översatta och sammansatta orden inleds med versal, vilket är tveksamt. Ändrar man detta blir det dock bara ord som riskerar att tappa sin viktiga betydelse. I stället skulle man kunna skriva så här:

Modulen Forum kräver att modulerna Taxonomy och Comment är aktiverade.

Synpunkter?

Hej.
Jag kan tänka mig att hjälpa till med översättningen.
Jag har nyligen gått över till Drupal på min sajt så det kanske inte går så fort med mina översättningar.

Har tagit mig an menu-module.po

Enable har dubbla betydelser vilket blir tydligt i följande från den gamla översättningen (beskrivningen av modulen Forum i infofilen):

Enables threaded discussions about general topics.
Aktiverar trådade diskussioner om allmänna ämnen.

Här ska helt klart enable ha betydelsen möjliggöra. Föreslår att den läggs in som alternativ i README där det just nu bara står aktivera som översättning.

Har fastnat på ordet "Content authoring form". I den gamla översättningen översätts det till både "nod-formulär" och "inläggsformulär".
Har funderat på "innehållspubliceringformulär" men det låter inte bra.
Några förslag?

Mitt förslag: "Formulär för att skapa innehåll".

Bifogar forum-module.po samt uppdaterade version av mina tidigare filer, i enligthet med diskussionen om att betrakta modulnamen som oöversatta egennamn (med inledande versal).

Nu paxar jag filter-module.po

"Inställningar för formulär för att skapa innehåll" som översättning till "Content authoring form settings" blir i mitt tycke inte bra. Inte heller meningen "Menymodulen ger möjlighet att skapa menyval direkt i formulären för att skapa innehåll." låter bra.
Vad sägs om "publiceringsformulär"?

En annan sak: I general.po är ordet "Operations" översatt till "Alternativ". Jag tycker att "hantering" eller "funktion" skulle vara bättre.

Jag tar search-module.po.

Operations var ett ord som redan var översatt, och jag får villigt erkänna att även om jag har tittat igenom alla strängar, så har jag inte ägnat lika mycket tid åt de "vita" (i poedit). Den man vill säga med det här ordet är att just i den aktuella vyn så finns de här alternativen/funktionerna som kan utföras/hanteras. Ser man till normala översättningar av ordet operations så är det väl närmast drift det här handlar om. Ett alternativ kan ju vara att kalla det för "Operationer". Tyskarna har gjort så. (Jag sneglar ibland på den tyska översättningen då det är den enda av de färdiga översättningarna som jag begriper. Dessutom är det ett språk som ligger mycket nära svenskan, så det kan ju få bli ett allmänt tips).

Sammanfattningsvis ser jag inget uppenbart alternativ till "Alternativ", men ska vi byta röstar jag på "Operationer", tror jag, nog...?

Här kommer menu-module.po och search-module.po. Hoppas det går bra med en zip-fil.
Jag har översatt "content authoring form" till "formulär för innehållsskapande" samt "operations" till "operationer".

Jag roffar åt mig upload-module.po och locale-module.po

Eftersom det verkar som det blev "operationer" så bifogar jag en uppdaterad general.po. Det är den som styr de flesta ställena där den här strängen förekommer.

Ändringarna i den nya versionen av potfilerna (för rc2?) är väl inte så stora, så det är kanske enklast att göra klart jobbet nu med rc1. Sen skapar zoo33 en "sv-5rc2-for_translation.tgz" och var och en uppgraderar drupal till rc2 och tar hand om sina moduler.

Här kommer upload-module.po och locale-module.po.

Nu tar jag comment-module.po

Om du tar comment-module har jag en synpunkt: "Preview comment" står i den gamla översättningen som "granska kommentar innan publicering". Även om "innan" numera är godkänt enligt språkvårdare, så tycker jag att "före" känns naturligare.

Här kommer filter-module.po.

Nu tar jag följande: blog-module.po, blogapi-module.po, book-module.po

Såg att den skarpa femman släpptes idag, så nu gäller det att snabbt få något som går att publicera. Här kommer i alla fall mitt senaste bidrag: blog-module.po, blogapi-module.po och book-module.po.

Nu tar jag följande: contact-module.po, tracker-module.po, watchdog-module.po

Här kommer filerna igen. Hoppas det går bättre nu.

Angående pot: Det är väl lite svårt att bryta mitt i arbetet och byta version, så vi jobbar väl färdigt med filerna från rc1, och sen slår vi ihop dem och gör en ny "msgmerge --compendium ...). I och för sig kan var och en göra "msgmerge --update" på sina filer, men utan --compendium missar man en massa översättningar som redan finns i andra moduler. I alla fall gäller det general.po där jag fick 59 strängar som var missing eller fuzzy på det viset, samtidigt som jag kände igen en hel del av dem från andra moduler.

Här kommer comment-module.po samt uppdaterade versioner av menu-module.po, upload-module.po, search-module.po och locale-module.po

Jag tar även statistics-module.po eftersom den hänger ihop med watchdog (som jag håller på med nu).

Här kommer contact, tracker, watchdog och statistics samt en uppdaterad system-module.po (hittade ett stavfel).

Nu tar jag poll-module.po och search-module.po.

Jag har uppenbarligen kommit i otakt med b-taggarna, så det här är ett försök att avsluta fetstilen.
Om det funkade ska det här se normalt ut.

Perf.
Search-module.po är redan klar.

Jag hjälper gärna till om det behövs.

Sorry, missade att search redan var bokad (två gånger dessutom, men det kvittar ju om den är klar).

Bland de filer som saknas hade jag redan fixat common-inc.po, så jag bifogar min version om den andra inte skulle dyka upp.

Kan man göra något? Jag har suttit och översatt en egen version av 5:an men tänkt att det är bättre att hjälpa till med att få den "officiella" versionen rumsfäig. :)

OK. Jag såg meddelandet nu. Jag tar den och kör igång. jag såg den där: www.foreby.se/README.html. Jag kikar på den.

Boletus: titta hellre på den README som ligger i CVS (länk på http://drupal.org/project/sv). Den version som ligger på min webserver är min ursprungliga version, och det har gjorts några små ändringar sedan jag gjorde den första kodningen.

Här kommer poll-module.po och theme-inc.po. Filen innehåller även color-module.po som jag glömde säga at jag tog. Men det är ju bara 11 strängar så det blev inte så mycket dubbelarbete. Zoo33: du kan ju använda den för att jämföra med din översättning.

Som en sista insats i den här rundan tar jag nu file-inc.po

Ok. Mycket bra översättningsprinciper! :)

Finns det någon aktuell och överenskommen nomenklatur för de olika menyvalen i admindelen?

Här kommer modulen Drupal. Det ligger med en fil som heter drupal-module.mo i arkivet (utöver .po-filen). PoEdit skapar den. Jag vet inte om den behövs?

Jag tar locale-inc.po

Här kommer locale-inc.po

Hur går det med transen? Kan man ta något?

Det är ett fel i statistics-översättningen. Pluralformen ska vara:

#: modules/statistics/statistics.module:92
msgid "1 read"
msgid_plural "@count reads"
msgstr[0] "1 läsning"
msgstr[1] "@count läsningar"

Det var ett %-tecken före count läsningar.

Så slarvigt att missa en ändrad placeholder. Jag har stött på det här problemet i samband med en pluralform tidigare, så jag gissar att update-placeholders.php inte klarar pluralis. I vilket fall som helst har jag uppdaterat statistics-module.po och bifogar den tillsammans med file-inc.po.

mo-filerna behövs inte och det går att stänga av genereringen i poedit under file->preferences->editor. Filen är en kompilerad variant av po-filen, och används av gettext. Dessutom behövs inte mo-filerna i Drupal eftersom man inte använder sig gettext utan använder sin egen databas för översättningnarna. Det är alltså bara formatet på po-filerna som är gemensamt med gettext, vilket är smart eftersom man kan använda samma verktyg.

När det gäller nomenklaturen i menyerna finns det väl ingen mer standard än det vi har pratat om tidigare, att huvudalternativen skulle heta Byggstenar, Innehåll, Inställningar, Användare, Loggar och Hjälp. I övrigt gäller det väl mest att hålla sig kort. Menyalternativ på flera rader blir lätt otydliga.

Jag har förresten stött på ett litet problem med mitt förslag att korta ned huvudnivåerna. Det har lett till följande hierarki: "Administrera->Innehåll->Innehåll". Är det något problem att Innehåll ligger under Innehåll? Alternativet är att förlänga eller byta ut det sista ledet. Byter man mellanledet till nåt längre måste nog de andra på samma nivå bytas av symmetriskäl, så det tycker jag inte är en bra idé.

Fast originalets "Administer->Content management->Content" är egentligen lika otydligt. Även om det ligger ett "management" efter ett av orden så betyder ju även här de två sista leden samma sak.

Om vi ska ändra det här är mitt förslag att ändra det sista "Innehåll" till "Inlägg", så blir det till och med tydligare än originalet. Synpunkter?

Inlägg blir bra. Innehåll-Innehåll låter inte så bra.

Korta menyval är precis min melodi. Jag blir galen av övertydliga menyer. Det blir så svårt att läsa dem så man missar mer i ren ögonirritation än vad man vinner i eventuellt utökad förståelse.

Byggstenar? :) Jag såg det. Jag är inte 100% övertygad. Konnotationen kan jag köpa. Men det låter väldigt malplacerat i sammanhanget. Site building och byggstenar är knappast synonymt.

Vad sägs om följande titel och förklarande undertext?
Arkitektur
Webbplatsens beståndsdelar: teman, moduler och funktioner.

Jag tycker personligen att byggstenar är ett bra ord, för de inställningar som finns under den här rubriken handlar just om de grundläggande delar som bygger upp utseendet. Jag har dock inget emot "Arkitektur" om någon mer vill ha det. Ordet har i princip samma grundbetydelse som mitt förslag.

Däremot tycker jag inte att ditt förslag på "undertext" är rikigt bra ("Webbplatsens beståndsdelar: teman, moduler och funktioner."). Den är så definitiv och utelämnar något av de mest grundläggande byggstenarna i Drupal, nämligen block och menyer. Inledningen med "beståndsdelar" är jag dock helt med på. Men även här skulle det vara trevligt med fler synpunkter.

Den längre texten används både som "tooltip" och som underrubrik i översikten över de administrativa funktionerna. Just när det gäller tooltips så finns det ett problem med firefox som klipper långa texter. Därför är det en fördel om man kan hålla dem så korta som det går utan att förvanska texten allt för mycket.

En viktig grundprincip vid översättning är att man inte gör en "Olmarks" och fabulerar fritt, utan håller sig till att göra just en översättning, utan att lägga till eller utelämna något. Har man synpunkter på originaltexten ska det inte lösas i översättningen, utan påpekas "upstream". Det här är en viktig princip, och tyvärr leder den ibland till lite krystade översättningar.

Avslutningsvis ser jag mycket positivt på att få synpunkter. Alternativet, att var och en bara gräver ned sig i sina egna moduler, kan leda till en översättning som haltar. Även om vi har README-filen så finns det så mycket mer som man behöver vara rimligt överens om. Jag ser fram emot en komplett sv.po inom kort, så att man kan börja gå igenom och se helheten (eftersom det är lite omständligt att ladda ned varje enskild fil och installera den).

Det var ett förslag bara. Men jag vidhåller fortfarande att byggstenar och site building inte riktigt betyder samma sak eller ger samma associationer. Det handlar ju inte bara om "stenarna" i sig utan om en mer övergripande arkitektonisk vinkel. Va? :)

Spånar:
Ramverk. Modell. Struktur. Uppbyggnad. Webbplatsens beståndsdelar.

Återkommer om detta om några timmar. Ge gärna förslag. Jag litar på ditt omdöme.

Vilken fil man ta sätta tänderna i? Jag vill också ha klart denna. Helst skulle man vilja ha en Ohlmarksvariant och en lite mer kort och koncis. Ohlmarksvarianten är bra när man ska lära sig. Sedan är det effektivitet som gäller. Jag bläddrar bland de som inte är gjorda och hojtar till om vilken jag tar.

Är det någon som lägger in min drupal-module? Jag varker vet hur man gör, eller har rättigheter antar jag. Hur får man rättigheter att lägga in filer i CSV:n?

Är allt gjort? Jag kan inte se någon fil som inte är tagen?

Jag får det också till att alla filer är klara. Så då väntar vi översättare bara på att någon projektmedlem (dvs zoo33) kör msgcat på filerna och sedan msgmerge mot den senaste versionen av po-filerna så att vi kan ta en runda till.

Om det bara är små ändringar i nästa runda lär det gå ganska snabbt. I så fall är det knappast lönt att släppa någon officiell version förrän vi är helt klara.

Och var är zoo33 då? Ska vi ringa honom? :) Jobbar du i Lund förresten? Jag ska flyga dít i morgon och besöka universitetssjukhuset.

//Magnus

Jag vet inte riktigt varför Drupal inte använder gettext fullt ut, men det kanske är för att det inte ska vara ett krav att PHP har stödet inkompilerat. Hade man behållit de separata po-filerna så hade det i så fall varit lätt att använda textdomain()/bindtextdomain() för att kunna ha samma sträng i olika domäner. Det borde i och för sig gå att dela upp översättningarna i olika domäner även om de ligger i databasen. Fördelen med en enda textdomän är dock att man inte riskera att samma begrepp översätts på olika sätt i olikda delar av Drupal.

Om man söker här, eller på google, så verkar det finnas väldigt mycket diskussioner kring det här, så det är nog utrett mer än en gång, och det finns därför säkert goda skäl för den nuvarande ordningen. I sammanhanget kan man förresten jämföra med squirrelmail som har olika textdomäner och har eget stöd för att läsa direkt i po-filerna, men använder gettext om det är tillgängligt.

Så över till en helt annan fråga: Hur fungerar det nästa gång det behövs hjälp med översättningarna? Är det någon som kontaktar de som har varit med tidigare, eller måste man själv hålla koll på om det dyker upp någon ny issue (till exempel med RSS)? I det senare fallet är nog risken att många aldrig upptäcker behovet förrän det är för sent. Är det kanske därför så få av de gamla översättarna är aktiva den här gången?

Tack själv. Synd att jag kom in så sent. Jag hittade er inte.

Om man översätter moduler, var ska man skicka filerna? Till moduladministratören eller?