Det er kommet inn en syntaksfeil i alle po-filer som inneholder msgid-plural, de jeg har sett hittil er i kdebase. Det ser ut til at den opprinnelige msgid er blitt herpet? Jeg har ikke nok kunnskap om svnt til å gå tilbake til tidligere versjoner, kan noen hjelpe?
mvh Bjørn
Bjørn Steensrud wrote:
Det er kommet inn en syntaksfeil i alle po-filer som inneholder msgid-plural, de jeg har sett hittil er i kdebase. Det ser ut til at den opprinnelige msgid er blitt herpet? Jeg har ikke nok kunnskap om svnt til å gå tilbake til tidligere versjoner, kan noen hjelpe?
Feilen i MagicPo selv er rettet, jeg holder på med jobben å rette selve strengen også.
Hilsen Axel
Axel Bojer wrote:
Bjørn Steensrud wrote:
Det er kommet inn en syntaksfeil i alle po-filer som inneholder msgid-plural, de jeg har sett hittil er i kdebase. Det ser ut til at den opprinnelige msgid er blitt herpet? Jeg har ikke nok kunnskap om svnt til å gå tilbake til tidligere versjoner, kan noen hjelpe?
Feilen i MagicPo selv er rettet, jeg holder på med jobben å rette selve strengen også.
Med mindre det er mer nå som jeg har oversett skal alle en-/flertallsfeilene nå være rettet og meldt inn :-D
Forøvrig finner jeg masse feil i ulike filer som jeg ikke forstår noe av, for når jeg går til den linja msgfmt -c melder om, så ser jeg en helt vanlig streng der som ikke ser det minste ødelagt ut. Kan det være noe med ulike versjoner av gettext e.l.?
Her er noen utdrag:
============================================================ Eksempel 1: -----------
msgfmt -c extragear-*/* extragear-base/akregator_konqplugin.po:4: duplisert definisjon av melding... extragear-addons/desktop_extragear-addons_kopete_skype.po:3: ...this is the location of the first definition msgfmt: (null): warning: PO file header missing or invalid warning: charset conversion will not work msgfmt: fant 2 fatale feil
Toppteksten i fila den klager over er:
# Translation of akregator_konqplugin to Norwegian Bokmål # Knut Yrvin knuty@skolelinux.no, 2005. # msgid "" msgstr "" "Project-Id-Version: akregator_konqplugin\n" "Report-Msgid-Bugs-To: http://bugs.kde.org%5Cn" "POT-Creation-Date: 2007-08-31 05:52+0200\n" "PO-Revision-Date: 2005-10-17 16:18+0200\n" "Last-Translator: MagicPO 0.3 (automated)\n" "Language-Team: Norwegian Bokmål i18n-nb@lister.ping.uio.no\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "X-Generator: MagicPO 0.3\n" "Plural-Forms: nplurals=2; plural=n != 1;\n"
Er dette så fatalt, da?
===========================================================
Eksempel 2: -----------
Stort sett melder msgfmt bare om «Parse error», f.eks:
kdebase/konqueror.po:687:1: parse error (+ en rekke med andre linjenummer)
kdeaccessibility/kmouth.po extragear-multimedia/amarok.po og kdebase/dolphin.po
er blant dem med spesielt mange slike.
============================================================
Ville vært fint om noen med mere kompetanse på dette kunne tatt en titt :-)
PS: I tilfelle jeg skulle ha klart å slette / glemme å legge inn igjen et strengepar (msgid+msgstr), da gjenskaper vel svn dette ved neste automatiske oppdatering?
Hilsen Axel
Onsdag 14. november 2007 skreiv Axel Bojer:
Forøvrig finner jeg masse feil i ulike filer som jeg ikke forstår noe av, for når jeg går til den linja msgfmt -c melder om, så ser jeg en helt vanlig streng der som ikke ser det minste ødelagt ut. Kan det være noe med ulike versjoner av gettext e.l.?
Det kunne vore det, men det er det ikkje. Uansett bør du oppdatera til gettext 0.17, som handterer sjekk av fleirtalstekstar og KDE-tekstar betre.
msgfmt -c extragear-*/* extragear-base/akregator_konqplugin.po:4: duplisert definisjon av melding... extragear-addons/desktop_extragear-addons_kopete_skype.po:3: ...this is the location of the first definition msgfmt: (null): warning: PO file header missing or invalid warning: charset conversion will not work msgfmt: fant 2 fatale feil
msgfmt handterer ikkje fleire filer slik du trur. Dei vert i praksis slegne saman til éi fil, som er grunnen til feilmeldinga om duplikatmeldingar.
Kommandoen du er ute etter er: find . -name '*.po' | while read fil; do msgfmt -c -o /dev/null $fil; done
Og denne finn fleire alvorlige feil. Eg vil verken oppdatera eller senda inn .po-filene før desse er retta.
Eksempel 2:
Stort sett melder msgfmt bare om «Parse error», f.eks:
kdebase/konqueror.po:687:1: parse error (+ en rekke med andre linjenummer)
Hos meg heiter det «syntaksfeil» (eg brukar vel dansk gettext), og er heilt riktig. Omsettinga har ikkje rett format samanlikna med originalteksten, og må rettast.
PS: I tilfelle jeg skulle ha klart å slette / glemme å legge inn igjen et strengepar (msgid+msgstr), da gjenskaper vel svn dette ved neste automatiske oppdatering?
Ja, msgid vert gjenoppretta. Omsettinga må du laga på nytt.
Karl Ove Hufthammer wrote:
Onsdag 14. november 2007 skreiv Axel Bojer:
Forøvrig finner jeg masse feil i ulike filer som jeg ikke forstår noe av, for når jeg går til den linja msgfmt -c melder om, så ser jeg en helt vanlig streng der som ikke ser det minste ødelagt ut. Kan det være noe med ulike versjoner av gettext e.l.?
Forøvrig: Jeg gikk til rett linje, da jeg da bare sjekket en og en fil, så det nedenfor er uavhengig av dette :-)
Det kunne vore det, men det er det ikkje. Uansett bør du oppdatera til gettext 0.17, som handterer sjekk av fleirtalstekstar og KDE-tekstar betre.
Hmm, ser jeg har 0.16.1, ja. Oppdatere til en annen gettext er ikke bare bare, antar jeg, og jeg bruker siste versjon av Kubuntu, som ellers har ganske nye pakker for det meste :-/
msgfmt -c extragear-*/* extragear-base/akregator_konqplugin.po:4: duplisert definisjon av melding... extragear-addons/desktop_extragear-addons_kopete_skype.po:3: ...this is the location of the first definition msgfmt: (null): warning: PO file header missing or invalid warning: charset conversion will not work msgfmt: fant 2 fatale feil
msgfmt handterer ikkje fleire filer slik du trur. Dei vert i praksis slegne saman til éi fil, som er grunnen til feilmeldinga om duplikatmeldingar.
Kommandoen du er ute etter er: find . -name '*.po' | while read fil; do msgfmt -c -o /dev/null $fil; done
Ok, jeg fant en annen en i mellomtiden: for x in $(ls *); do msgfmt -c $x; done
Og denne finn fleire alvorlige feil. Eg vil verken oppdatera eller senda inn .po-filene før desse er retta.
Klarer du å rette dem? Jeg prøvde å se, men ser ingen syntaksfeil jeg gjenkjenner. Kan det være henvisningene som er feil? I den ene fila så jeg at disse var helt ulike (altså a la, men ikke presist: #: libs/dimg/loaders/pngsettings.cpp:83 istedenfor #: libs/dimg/loaders/pngsettings.cpp:73 som jeg fant i en tidligere innsjekket versjon.)
Vet ikke helt hvorfor dette har oppstått, uansett gjaldt akkurat det vel bare en fil, såvidt jeg kan huske.
Eksempel 2:
Stort sett melder msgfmt bare om «Parse error», f.eks:
kdebase/konqueror.po:687:1: parse error (+ en rekke med andre linjenummer)
Hos meg heiter det «syntaksfeil» (eg brukar vel dansk gettext), og er heilt riktig. Omsettinga har ikkje rett format samanlikna med originalteksten, og må rettast.
Hva er feil? Og hvordan rettes dette?
PS: I tilfelle jeg skulle ha klart å slette / glemme å legge inn igjen et strengepar (msgid+msgstr), da gjenskaper vel svn dette ved neste automatiske oppdatering?
Ja, msgid vert gjenoppretta. Omsettinga må du laga på nytt.
Av den ene strengen mener du vel?
Hilsen Axel
Axel Bojer:
Det kunne vore det, men det er det ikkje. Uansett bør du oppdatera til gettext 0.17, som handterer sjekk av fleirtalstekstar og KDE-tekstar betre.
Hmm, ser jeg har 0.16.1, ja. Oppdatere til en annen gettext er ikke bare bare, antar jeg,
Jo, det er like lett som å oppdatera alle andre pakkar: ./configure --prefix=/usr make sudo make install
og jeg bruker siste versjon av Kubuntu, som ellers har ganske nye pakker for det meste :-/
gettext 0.17 er heilt ny (men er inkludert i oppdateringane til for eksempel Mandriva Linux, som eg brukar).
Kommandoen du er ute etter er: find . -name '*.po' | while read fil; do msgfmt -c -o /dev/null $fil; done
Ok, jeg fant en annen en i mellomtiden: for x in $(ls *); do msgfmt -c $x; done
Denne vil berre sjekka filene i gjeldande mappe, mens min vil sjekka alle filer i mappa og undermappene, som er nyttig når du står i f.eks. nb/messages.
Og denne finn fleire alvorlige feil. Eg vil verken oppdatera eller senda inn .po-filene før desse er retta.
Klarer du å rette dem?
Eg føretrekker å ikkje måtte retta andres feil …
Jeg prøvde å se, men ser ingen syntaksfeil jeg gjenkjenner.
På den fila eg sjekka, var syntaksen heilt forskjellig i msgid-en og msgstr-en.
Kan det være henvisningene som er feil?
Nei.
Hos meg heiter det «syntaksfeil» (eg brukar vel dansk gettext), og er heilt riktig. Omsettinga har ikkje rett format samanlikna med originalteksten, og må rettast.
Hva er feil? Og hvordan rettes dette?
Gje eit eksempel på ein feil du ikkje ser.
Ja, msgid vert gjenoppretta. Omsettinga må du laga på nytt.
Av den ene strengen mener du vel?
Ja.
Karl Ove Hufthammer wrote:
Axel Bojer:
Jeg prøvde å se, men ser ingen syntaksfeil jeg gjenkjenner.
På den fila eg sjekka, var syntaksen heilt forskjellig i msgid-en og msgstr-en.
Hvilke? Hvilken forskjell?
Hos meg heiter det «syntaksfeil» (eg brukar vel dansk gettext), og er heilt riktig. Omsettinga har ikkje rett format samanlikna med originalteksten, og må rettast.
Hva er feil? Og hvordan rettes dette?
Gje eit eksempel på ein feil du ikkje ser.
./kdeaccessibility/kmouth.po:48:1: parse error ./kdeaccessibility/kmouth.po:54:1: parse error (...)
La oss se: 47 #, fuzzy 48 msgid "without name" 49 msgstr "Bjørn Steensrud"
53 #, fuzzy 54 msgid "Export Dictionary" 55 msgstr "Eksporter ordbok"
Disse er to eksempler på strenger der det meldes om feil, men som tatt for seg ser helt harmløse ut.
Hilsen Axel
Axel Bojer:
Karl Ove Hufthammer wrote:
Axel Bojer:
Jeg prøvde å se, men ser ingen syntaksfeil jeg gjenkjenner.
På den fila eg sjekka, var syntaksen heilt forskjellig i msgid-en og msgstr-en.
Hvilke? Hvilken forskjell?
Eg såg på konqueror.po, der det mangla to HTML-taggar i omsettinga.
./kdeaccessibility/kmouth.po:48:1: parse error ./kdeaccessibility/kmouth.po:54:1: parse error (...)
La oss se: 47 #, fuzzy 48 msgid "without name" 49 msgstr "Bjørn Steensrud"
Disse er to eksempler på strenger der det meldes om feil, men som tatt for seg ser helt harmløse ut.
Viss du fjerner linjene som begynner med #| forsvinn desse feilmeldingane.
Prøv for eksempel: sed -i '/^#|/d' kmouth.po
Karl Ove Hufthammer:
Disse er to eksempler på strenger der det meldes om feil, men som tatt for seg ser helt harmløse ut.
Viss du fjerner linjene som begynner med #| forsvinn desse feilmeldingane.
Dei fleste av desse kom for øvrig med di innmelding 56707, med teksten «Rettede en-/flertallsformer». Der flytta du linjene frå å stå *under* linja #,fuzzy til å stå over denne linja. Dette er ein syntaksfeil.
Karl Ove Hufthammer wrote:
Axel Bojer:
Karl Ove Hufthammer wrote:
Axel Bojer:
Jeg prøvde å se, men ser ingen syntaksfeil jeg gjenkjenner.
På den fila eg sjekka, var syntaksen heilt forskjellig i msgid-en og msgstr-en.
Hvilke? Hvilken forskjell?
Eg såg på konqueror.po, der det mangla to HTML-taggar i omsettinga.
./kdeaccessibility/kmouth.po:48:1: parse error ./kdeaccessibility/kmouth.po:54:1: parse error (...)
La oss se: 47 #, fuzzy 48 msgid "without name" 49 msgstr "Bjørn Steensrud"
Disse er to eksempler på strenger der det meldes om feil, men som tatt for seg ser helt harmløse ut.
Viss du fjerner linjene som begynner med #| forsvinn desse feilmeldingane.
Prøv for eksempel: sed -i '/^#|/d' kmouth.po
Takk :-D
Den gjorde altså susen.
I andre filer var det bare linja med informasjon om språkgruppa som manglet. Med disse to rettelsene finner nå msgftm -c ingen flere feil i nb/messages :-)
Forøvrig forstår jeg ikke hvorfor #|regnes som syntaksfeil, # angir jo at det er en kommentar, og der burde man vel kunne sette hva som helst?
Hilsen Axel
Axel Bojer:
Prøv for eksempel: sed -i '/^#|/d' kmouth.po
Takk :-D
Den gjorde altså susen.
I andre filer var det bare linja med informasjon om språkgruppa som manglet. Med disse to rettelsene finner nå msgftm -c ingen flere feil i nb/messages :-)
Fint. :)
Forøvrig forstår jeg ikke hvorfor #|regnes som syntaksfeil, # angir jo at det er en kommentar, og der burde man vel kunne sette hva som helst?
Nei, det er «# » som angjev at det er ein kommentar, og kommentarar skal/må stå øvst. Full syntaks for ein vanlig tekst utan fleirtalsformer er:
white-space # translator-comments #. extracted-comments #: reference... #, flag... #| msgid previous-untranslated-string msgid untranslated-string msgstr translated-string
Axel Bojer:
I andre filer var det bare linja med informasjon om språkgruppa som manglet. Med disse to rettelsene finner nå msgftm -c ingen flere feil i nb/messages :-)
Det er syntaksfeil i fire filer i kde3-stable/nb som bør rettast. (Det er òg feil nynorskfilene her, men dei kan eg retta.)
Torsdag 15. november 2007 skreiv Karl Ove Hufthammer:
Det er syntaksfeil i fire filer i kde3-stable/nb som bør rettast. (Det er òg feil nynorskfilene her, men dei kan eg retta.)
Tvilar på at alt her bør reknast som feil. Berre oversjå det. Får satsa på at strengformateringane er meir fleksible i KDE 4.
Karl Ove Hufthammer wrote:
Torsdag 15. november 2007 skreiv Karl Ove Hufthammer:
Det er syntaksfeil i fire filer i kde3-stable/nb som bør rettast. (Det er òg feil nynorskfilene her, men dei kan eg retta.)
Tvilar på at alt her bør reknast som feil. Berre oversjå det. Får satsa på at strengformateringane er meir fleksible i KDE 4.
Ja, nå driver jeg på med litt manuell retting, og får feil når jeg vil oversette
Unable to open \n %1 \n for writing
med
Kunne ikke skrive til \n %1 \n
da programmet insisterer på at det skal stå noe etter \n :-( (extragear-base/domtreeviewer, kde4)
Hilsen Axel
Torsdag 15. november 2007 skreiv Axel Bojer:
Ja, nå driver jeg på med litt manuell retting, og får feil når jeg vil oversette
Unable to open \n %1 \n for writing
med
Kunne ikke skrive til \n %1 \n
da programmet insisterer på at det skal stå noe etter \n :-( (extragear-base/domtreeviewer, kde4)
Nei, her har programmet rett og du feil, ser det ut til. Problemet er at di omsetting sluttar med ein «\n», mens originalteksten ikkje gjer det. Berre fjern «\n»-en, so skal alt vera OK.
Karl Ove Hufthammer wrote:
Torsdag 15. november 2007 skreiv Axel Bojer:
Ja, nå driver jeg på med litt manuell retting, og får feil når jeg vil oversette
Unable to open \n %1 \n for writing
med
Kunne ikke skrive til \n %1 \n
da programmet insisterer på at det skal stå noe etter \n :-( (extragear-base/domtreeviewer, kde4)
Nei, her har programmet rett og du feil, ser det ut til. Problemet er at di omsetting sluttar med ein «\n», mens originalteksten ikkje gjer det. Berre fjern «\n»-en, so skal alt vera OK.
Å, jeg trodde feilen var at det skulle være like mange /n begge steder, så jeg lurte programmet ved å legge til et mellomrom etter \n, og da ble den fornøyd, naja ...
-Axel
Axel Bojer:
Ok, jeg fant en annen en i mellomtiden: for x in $(ls *); do msgfmt -c $x; done
Dette vil for øvrig strø frå seg fila «messages.mo», som du då må passa på å *ikkje* senda inn til SVN.
Karl Ove Hufthammer wrote:
Axel Bojer:
Ok, jeg fant en annen en i mellomtiden: for x in $(ls *); do msgfmt -c $x; done
Dette vil for øvrig strø frå seg fila «messages.mo», som du då må passa på å *ikkje* senda inn til SVN.
Ja, jeg oppdaget det :-) Har unngått den tabben, i det minste.
Hilsen Axel
* Karl Ove Hufthammer karl@huftis.org [2007-11-15]:
Axel Bojer:
Ok, jeg fant en annen en i mellomtiden: for x in $(ls *); do msgfmt -c $x; done
Dette vil for øvrig strø frå seg fila «messages.mo», som du då må passa på å *ikkje* senda inn til SVN.
Heldigvis så krever SVN at du gjør en eksplisitt "svn add" før du kan sende inn slike midlertidige/nye filer - det skal mye til å gjøre den feilen ...
Hvis man er litt lur så setter man opp SVN til å ignorere messages.mo - bruk "svn propset" og gi "svn:ignore" en fornuftig verdi. Dessverre så må hver enkelt bruker legge til slik ignorering - du kan ikke kontrollere det fra tjeneren (slik du kan med CVS med $CVSROOT/CVSROOT/cvsignore).
OK, nå er vi nok off-topic.
Hans
Hans F. Nordhaug:
Dette vil for øvrig strø frå seg fila «messages.mo», som du då må passa på å *ikkje* senda inn til SVN.
Heldigvis så krever SVN at du gjør en eksplisitt "svn add" før du kan sende inn slike midlertidige/nye filer - det skal mye til å gjøre den feilen ...
Hugsar det var eit Windows-program som la til filer i CVS automatisk. Det var ikkje so kjekt. TortoiseCVS? No finst jo TortoiseSVN. Men det er Windows-program, og håpar ingen brukar Windows-program her. :)
Hvis man er litt lur så setter man opp SVN til å ignorere messages.mo
- bruk "svn propset" og gi "svn:ignore" en fornuftig verdi. Dessverre
så må hver enkelt bruker legge til slik ignorering - du kan ikke kontrollere det fra tjeneren (slik du kan med CVS med $CVSROOT/CVSROOT/cvsignore).
Å? SVN-eigenskapar som «svn:ignore» vert jo lagra på tenaren. Det er vel berre å ta «svn commit» på dei mappene du har endra svn:ignore-eigenskapane på?
On Thursday 15 November 2007 11:13:43 Karl Ove Hufthammer wrote:
Hans F. Nordhaug:
Hvis man er litt lur så setter man opp SVN til å ignorere messages.mo
- bruk "svn propset" og gi "svn:ignore" en fornuftig verdi. Dessverre
så må hver enkelt bruker legge til slik ignorering - du kan ikke kontrollere det fra tjeneren (slik du kan med CVS med $CVSROOT/CVSROOT/cvsignore).
Å? SVN-eigenskapar som «svn:ignore» vert jo lagra på tenaren. Det er vel berre å ta «svn commit» på dei mappene du har endra svn:ignore-eigenskapane på?
Ja.
Mvh, Lars Ivar Igesund
* Karl Ove Hufthammer karl@huftis.org [2007-11-15]:
Hans F. Nordhaug:
Dette vil for øvrig strø frå seg fila «messages.mo», som du då må passa på å *ikkje* senda inn til SVN.
Heldigvis så krever SVN at du gjør en eksplisitt "svn add" før du kan sende inn slike midlertidige/nye filer - det skal mye til å gjøre den feilen ...
Hugsar det var eit Windows-program som la til filer i CVS automatisk. Det var ikkje so kjekt. TortoiseCVS? No finst jo TortoiseSVN. Men det er Windows-program, og håpar ingen brukar Windows-program her. :)
Joda, det er minst en TortoiseSVN-brukere her :-) Når man er på jobb, så er det Windows som er standarden. Jeg kan ellers melde at TortoiseSVN ikke legger til filer automatisk ved commit.
Hvis man er litt lur så setter man opp SVN til å ignorere messages.mo
- bruk "svn propset" og gi "svn:ignore" en fornuftig verdi. Dessverre
så må hver enkelt bruker legge til slik ignorering - du kan ikke kontrollere det fra tjeneren (slik du kan med CVS med $CVSROOT/CVSROOT/cvsignore).
Å? SVN-eigenskapar som «svn:ignore» vert jo lagra på tenaren. Det er vel berre å ta «svn commit» på dei mappene du har endra svn:ignore-eigenskapane på?
Du har rett, ser det ut til (og jeg skjønner helt hvor jeg har det fra at det ble kun lagret lokalt), og det er jo helt flott. Dessverre er det likevel en ulempe med svn:ignore - "The patterns are strictly for that directory - they do not carry recursively into subdirectories." Uansett, det var bare et tips for å unngå problemer med messages.mo.
Hans
* Hans F. Nordhaug Hans.F.Nordhaug@hiMolde.no [2007-11-15]:
- Karl Ove Hufthammer karl@huftis.org [2007-11-15]:
[kutt]
Å? SVN-eigenskapar som «svn:ignore» vert jo lagra på tenaren. Det er vel berre å ta «svn commit» på dei mappene du har endra svn:ignore-eigenskapane på?
Du har rett, ser det ut til (og jeg skjønner helt hvor jeg har det fra
^^^^ IKKE
at det ble kun lagret lokalt), og det er jo helt flott. Dessverre er det likevel en ulempe med svn:ignore - "The patterns are strictly for that directory - they do not carry recursively into subdirectories." Uansett, det var bare et tips for å unngå problemer med messages.mo.
Hans
Hans F. Nordhaug:
Å? SVN-eigenskapar som «svn:ignore» vert jo lagra på tenaren. Det er vel berre å ta «svn commit» på dei mappene du har endra svn:ignore-eigenskapane på?
Du har rett, ser det ut til (og jeg skjønner helt hvor jeg har det fra at det ble kun lagret lokalt), og det er jo helt flott. Dessverre er det likevel en ulempe med svn:ignore - "The patterns are strictly for that directory - they do not carry recursively into subdirectories."
Men det er lett å unngå, ved å setta det rekursivt. Prøv for eksempel: svn -R propset svn:ignore messages.mo * når du for eksempel står i mappa «i18n». svn status viser at du har gjort endringar for alle mapper og undermapper.
Eg har ikkje passordet mitt for handa nett no, so nokon kan godt senda inn den ovenståande endringa.
* Karl Ove Hufthammer karl@huftis.org [2007-11-15]:
Hans F. Nordhaug:
Å? SVN-eigenskapar som «svn:ignore» vert jo lagra på tenaren. Det er vel berre å ta «svn commit» på dei mappene du har endra svn:ignore-eigenskapane på?
Du har rett, ser det ut til (og jeg skjønner helt hvor jeg har det fra at det ble kun lagret lokalt), og det er jo helt flott. Dessverre er det likevel en ulempe med svn:ignore - "The patterns are strictly for that directory - they do not carry recursively into subdirectories."
Men det er lett å unngå, ved å setta det rekursivt. Prøv for eksempel: svn -R propset svn:ignore messages.mo * når du for eksempel står i mappa «i18n». svn status viser at du har gjort endringar for alle mapper og undermapper.
OK, dette er tydeligvis ikke min beste dag - jeg burde gi meg nå ;-) Jeg er jo klar over at "-R" finnes ...
Problemet med kommandoen propset er at den overskriver eksisterende verdier (for svn:ignore). For eksempel for nettopp mappa i18n. (Jeg har ikke sjekket de andre mappene.) Det burde vært en propadd ...
Hans