Closed Bug 297896 Opened 20 years ago Closed 19 years ago

bug voor het melden van fouten in 1.1+ nl (2)

Categories

(Mozilla Localizations :: nl / Dutch, defect)

Product:
Mozilla Localizations
Component:
nl / Dutch
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mad_maks, Unassigned)

References

(
URL
)

Details

Attachments

(1 file, 37 obsolete files)

het is dus gifs
5.46 KB, message/rfc822
Details 
Vervolg op bug 291678.
Nog ייn patchje in bug 291678 geplaatst.
Correcties n.a.v. recente wijzigingen en andere kleinigheidjes.
(In reply to comment #2)
> Created an attachment (id=186796) [edit]
> Correcties n.a.v. recente wijzigingen
> 
> Correcties n.a.v. recente wijzigingen en andere kleinigheidjes.

Een afkorting krijgt in het meervoud toch echt wel een apostrof, dus GIF’s (de '
mag wel in een ’ veranderd worden)

En `de afbeelding ... omdat HIJ fouten bevat' dat is nu eens een reden waarom ik
graag een Vlaamse versie zou zien!  De afbeelding is wel degelijk een vrouwelijk
woord.  Maar het is nu eenmaal zo dat hier in Nederland geen onderscheid meer
wordt gemaakt, jammer als je het mij vraagt!  (Er staat expliciet een (v.) in
het GB!)

+ImageMapPolyWrongNumberOfCoords=Het "coords"-attribuut van de <area
shape="poly">-tag is niet in het "x1, y1, x2, y2 ..."-formaat.
Hierin zou ik, net als bij de twee regels erboven, de laatste `het' weglaten.

Wat is er mis met syntaxfout?

Verder: goeie!
(In reply to comment #3)
> (In reply to comment #2)
> Een afkorting krijgt in het meervoud toch echt wel een apostrof, dus GIF’s (de 
> mag wel in een ’ veranderd worden)
> 

Behalve als hij niet als afkorting wordt uitgesproken en dus onder de categorie
'cd-roms' valt.

> En `de afbeelding ... omdat HIJ fouten bevat' dat is nu eens een reden waarom ik
> graag een Vlaamse versie zou zien!  De afbeelding is wel degelijk een vrouwelijk
> woord.

Ik heb gehandeld uit gevoel en bij opzoeken aangenomen dat dezelfde regels
gelden als voor het betrekkelijk voonaamwoord waardoor het 'hij' zou worden
vanwege het de-woord, niet vanwege het woordgeslacht. Het blijkt echter om een
verwijswoord te gaan en het lijkt erop dat je dan inderdaad gelijk hebt.

> Maar het is nu eenmaal zo dat hier in Nederland geen onderscheid meer
> wordt gemaakt, jammer als je het mij vraagt!  (Er staat expliciet een (v.) in
> het GB!)
>

Ik heb hier nooit zo bij stilgestaan maar kan het wel begrijpen; woordgeslacht
is iets waar men zich in Nederland nauwelijks meer mee bezighoudt en wellicht is
dat de reden dat men (en dus ook ik) de 'fout' maakt door het lidwoord als
leidraad te gebruiken. Het zou me echter niet verbazen als dat ooit een nieuwe
regel gaat worden. Anyway, ik wil het wel terugzetten maar het zal
waarschijnlijk een opvallende uitzondering zijn in de teksten. Mening van anderen?

> +ImageMapPolyWrongNumberOfCoords=Het "coords"-attribuut van de <area
> shape="poly">-tag is niet in het "x1, y1, x2, y2 ..."-formaat.
> Hierin zou ik, net als bij de twee regels erboven, de laatste `het' weglaten.
> 

Omdat?

> Wat is er mis met syntaxfout?
> 

Syntax is Engels, syntaxis Nederlands, dus syntax error of syntaxisfout.

(In reply to comment #4)
> (In reply to comment #3)
> > (In reply to comment #2)
> > Een afkorting krijgt in het meervoud toch echt wel een apostrof, dus GIF’s (de 
> > mag wel in een ’ veranderd worden)
> > 
> 
> Behalve als hij niet als afkorting wordt uitgesproken en dus onder de categorie
> 'cd-roms' valt.

Je parafraseert de regel wel heel vrij.  Ik citeer: `In letterwoorden ei niet al
zodanig herkenbaar zijn, wordt geen apostrof gebruikt' (GB, 16e oplage).  Het
feit alleen al dat GIF met hoofdletters geschreven wordt, sluit het van deze
regel uit.

> > En `de afbeelding ... omdat HIJ fouten bevat' dat is nu eens een reden waarom ik
> > graag een Vlaamse versie zou zien!  De afbeelding is wel degelijk een vrouwelijk
> > woord.
> 
> Ik heb gehandeld uit gevoel en bij opzoeken aangenomen dat dezelfde regels
> gelden als voor het betrekkelijk voonaamwoord waardoor het 'hij' zou worden
> vanwege het de-woord, niet vanwege het woordgeslacht. Het blijkt echter om een
> verwijswoord te gaan en het lijkt erop dat je dan inderdaad gelijk hebt.
> 
> > Maar het is nu eenmaal zo dat hier in Nederland geen onderscheid meer
> > wordt gemaakt, jammer als je het mij vraagt!  (Er staat expliciet een (v.) in
> > het GB!)
> >
> 
> Ik heb hier nooit zo bij stilgestaan maar kan het wel begrijpen; woordgeslacht
> is iets waar men zich in Nederland nauwelijks meer mee bezighoudt en wellicht is
> dat de reden dat men (en dus ook ik) de 'fout' maakt door het lidwoord als
> leidraad te gebruiken. Het zou me echter niet verbazen als dat ooit een nieuwe
> regel gaat worden. Anyway, ik wil het wel terugzetten maar het zal
> waarschijnlijk een opvallende uitzondering zijn in de teksten. Mening van anderen?

Net hierom vind ik het wel ok zoals het is, ik wou alleen maar aanduiden dat dit
op mij zeer `Hollands' aandoet.  Ik kan er gerust mee leven als het blijft zoals
het is.  Wel zal je merken dat ik, waar mogelijk, dit probleem omzeil door
`deze' o.i.d. te gebruiken.

> > +ImageMapPolyWrongNumberOfCoords=Het "coords"-attribuut van de <area
> > shape="poly">-tag is niet in het "x1, y1, x2, y2 ..."-formaat.
> > Hierin zou ik, net als bij de twee regels erboven, de laatste `het' weglaten.
> > 
> 
> Omdat?

Consistentie?
 
> > Wat is er mis met syntaxfout?
> > 
> 
> Syntax is Engels, syntaxis Nederlands, dus syntax error of syntaxisfout.

ACK.

(In reply to comment #4)
> Ik heb gehandeld uit gevoel en bij opzoeken aangenomen dat dezelfde regels
> gelden als voor het betrekkelijk voonaamwoord waardoor het 'hij' zou worden
> vanwege het de-woord, niet vanwege het woordgeslacht. Het blijkt echter om een
> verwijswoord te gaan en het lijkt erop dat je dan inderdaad gelijk hebt.

‘Zij’ is hier natuurlijk ook goed (en niet alleen in het Vlaams), maar ‘hij’ is
volgens mij niet fout.


> Ik heb hier nooit zo bij stilgestaan maar kan het wel begrijpen; woordgeslacht
> is iets waar men zich in Nederland nauwelijks meer mee bezighoudt en wellicht is
> dat de reden dat men (en dus ook ik) de 'fout' maakt door het lidwoord als
> leidraad te gebruiken. Het zou me echter niet verbazen als dat ooit een nieuwe
> regel gaat worden. Anyway, ik wil het wel terugzetten maar het zal
> waarschijnlijk een opvallende uitzondering zijn in de teksten. Mening van anderen?

Ik zou ‘ze’ gebruiken.

Er is in het Nederlands wel onderscheid tussen geslacht natuurlijk, er is ten
slotte altijd nog onzijdig (het) en woorden hebben in principe ook een mannelijk
of een vrouwelijk geslacht, maar aangezien er geen duidelijk verschil is zoals
bijv. die en der in het Duits, leren mensen het onderscheid ook niet meer en
wordt er voor zover ik weet over het algemeen gewoon hij gebruikt tenzij een
woord overduidelijk vrouwelijk is (de poes, de venus). Overigens vind ik dat je
bij ‘het schaap’ toch ook van een ‘zij’ spreekt, maar goed :).

Tenminste, dat is hoe ik het mij herinner :). Ik let niet echt bewust op hoe ik
het toepas.


> > +ImageMapPolyWrongNumberOfCoords=Het "coords"-attribuut van de <area
> > shape="poly">-tag is niet in het "x1, y1, x2, y2 ..."-formaat.
> > Hierin zou ik, net als bij de twee regels erboven, de laatste `het' weglaten.
> 
> Omdat?

Het kan ook zonder, en dat ben ik wel met Hendrik eens dat dat nét iets
lekkerder leest.


> > Wat is er mis met syntaxfout?
> 
> Syntax is Engels, syntaxis Nederlands, dus syntax error of syntaxisfout.

Goeie :). Syntaxisfout, mooi woord ^_^.


~Grauw
(In reply to comment #6)
> (In reply to comment #4)
> > Ik heb gehandeld uit gevoel en bij opzoeken aangenomen dat dezelfde regels
> > gelden als voor het betrekkelijk voonaamwoord waardoor het 'hij' zou worden
> > vanwege het de-woord, niet vanwege het woordgeslacht. Het blijkt echter om een
> > verwijswoord te gaan en het lijkt erop dat je dan inderdaad gelijk hebt.
> 
> ‘Zij’ is hier natuurlijk ook goed (en niet alleen in het Vlaams), maar ‘hij’ is
> volgens mij niet fout.
> 
> 
> > Ik heb hier nooit zo bij stilgestaan maar kan het wel begrijpen; woordgeslacht
> > is iets waar men zich in Nederland nauwelijks meer mee bezighoudt en wellicht is
> > dat de reden dat men (en dus ook ik) de 'fout' maakt door het lidwoord als
> > leidraad te gebruiken. Het zou me echter niet verbazen als dat ooit een nieuwe
> > regel gaat worden. Anyway, ik wil het wel terugzetten maar het zal
> > waarschijnlijk een opvallende uitzondering zijn in de teksten. Mening van
anderen?
> 
> Ik zou ‘ze’ gebruiken.
> 
> Er is in het Nederlands wel onderscheid tussen geslacht natuurlijk, er is ten
> slotte altijd nog onzijdig (het) en woorden hebben in principe ook een mannelijk
> of een vrouwelijk geslacht, maar aangezien er geen duidelijk verschil is zoals
> bijv. die en der in het Duits, leren mensen het onderscheid ook niet meer en
> wordt er voor zover ik weet over het algemeen gewoon hij gebruikt tenzij een
> woord overduidelijk vrouwelijk is (de poes, de venus). Overigens vind ik dat je
> bij ‘het schaap’ toch ook van een ‘zij’ spreekt, maar goed :).

Dan heb je nog niet goed naar je landgenoten geluisterd.  Persoonlijk krijg ik
koude rillingen als ik iemand naast me hoor zeggen over de zon: kijk, hij gaat
onder, of over een koe: hij staat te herkauwen.
Als ik even de (officieuze) linguïst in mij laat spreken: het woordgenus in het
Nederlands in Nederland is gereduceerd tot het verschil tussen de en het.  Enkel
voor personen wordt er nog het verschil tussen `hij' en `zij' gemaakt. 
In Vlaanderen is dit heel anders, daar in de meeste dialecten (en in het
`Standaardvlaams') zelfs een verschil gemaakt wordt in het lidwoord (dus de
wolk, maar den boom).  Met als resultaat dat Vlamingen wel nog een gevoel hebben
voor het verschil in geslacht.

Maar zoals gezegd, ik vind het niet nodig om hier in de schrijftaal moeilijk
over te doen.  Meestal kan het probleem met `deze' o.i.d. omzeild worden.
Ach, ik had er niet over moeten beginnen :-(
Wel, is leuk en interessant :).

Vlaams is op veel punten heel gaaf, en ik vind het eigenlijk een mooiere taal
dan ‘gewoon’ Nederlands omdat het dicter bij de roots zit, en tegelijkertijd ook
veel deftige Franse woorden gebruikt, en overal formeel u ipv. informeel je.
Mooi om naar te luisteren ook, trouwens.

Maar ja... hij/zij is idd nogal moeilijk als je niet weet welke woorden hij en
welke zij zijn :). Overigens heb eerder de neiging om ze te schrijven, niet zij
(onze poes, ze neemt een levende muis mee het huis in). Maar dat doe ik
eigenlijk alleen wanneer ik me echt van het geslacht bewust ben, zoals bij onze
poes, ik zal bij een koe ongetwijfeld ook per ongeluk hij zeggen. Maar als
iemand me daar op zou wijzen zou ik het wel veranderen in ze.


~Grauw

heh, *kuch* forum *kuch* ;)
Comment on attachment 186796 [details] [diff] [review]
Correcties n.a.v. recente wijzigingen

patch is toegepast

ik heb 2 veranderingen aan de patch gemaakt:
- Gif's 
- afbeelding/ ze

Het het verhaal bij ImageMapPolyWrongNumberOfCoords heb ik wel laten staan.
Attachment #186796 - Attachment is obsolete: true
(In reply to comment #5)

> Je parafraseert de regel wel heel vrij.  Ik citeer: `In letterwoorden ei niet al
> zodanig herkenbaar zijn, wordt geen apostrof gebruikt' (GB, 16e oplage).  Het
> feit alleen al dat GIF met hoofdletters geschreven wordt, sluit het van deze
> regel uit.

Misschien vrij, maar niet zonder reden. Toevallig wordt gif hier even met
hoofdletters gebruikt maar normaalgesproken niet vaak en bovendien te allen
tijde als woord uitgesproken. Net als bijv. .doc is het een bestandsextensie die
andersoortig is dan bijvoorbeeld het aangehaalde voorbeeld van GOM's bij
Taaltelefoon (schreef men 'rom' ook niet ooit met grote letters?) dus het punt
van grote of kleine letters lijkt me zowiezo geen goede leidraad. Ik heb ook
nooit iemand horen praten over een een aantal gee-ie-efs; zou dat wel zo zijn
dan had je mijns inziens gelijk. Bovendien zou men dan ook niet spreken over
gifjes maar over gif'jes en dat lijkt me niet het geval.

> 
> Consistentie?
>  

Met wat?

(In reply to comment #10)
> (In reply to comment #5)
> 
> > Je parafraseert de regel wel heel vrij.  Ik citeer: `In letterwoorden die
niet als
> > zodanig herkenbaar zijn, wordt geen apostrof gebruikt' (GB, 16e oplage).  Het
> > feit alleen al dat GIF met hoofdletters geschreven wordt, sluit het van deze
> > regel uit.
> 
> Misschien vrij, maar niet zonder reden. Toevallig wordt gif hier even met
> hoofdletters gebruikt maar normaalgesproken niet vaak en bovendien te allen
> tijde als woord uitgesproken. Net als bijv. .doc is het een bestandsextensie die
> andersoortig is dan bijvoorbeeld het aangehaalde voorbeeld van GOM's bij
> Taaltelefoon (schreef men 'rom' ook niet ooit met grote letters?) dus het punt
> van grote of kleine letters lijkt me zowiezo geen goede leidraad. Ik heb ook
> nooit iemand horen praten over een een aantal gee-ie-efs; zou dat wel zo zijn
> dan had je mijns inziens gelijk. Bovendien zou men dan ook niet spreken over
> gifjes maar over gif'jes en dat lijkt me niet het geval.

Ik denk dat je te veel in computermilieus vertoeft om hier een realistisch beeld
te hebben.  90% van de Nederlandstaligen weet waarschijnlijk niet eens wat een
gif is.  En ok, die hoofdletters doen er niet veel toe, in dat verband verwijs
ik naar een recent artikeltje in Onze Taal, dat ik jammer genoeg niet online kan
terugvinden.  Hun advies was rond pdf: als je spreekt van een document, dan mag
je spreken van een pdf, of een pdf'je, met kleine letters. Spreek je echter van
het formaat, dan wordt het PDF, met grote.  Dat zou dus betekenendat we hier ook
gif's moeten schrijven.  Wat betreft de apostrof, is dit enigszins een
aanduiding: http://www.onzetaal.nl/advies/gsmetje.html, en ook de verwijzing
daarin.  
Overigens zijn ook de voorbeelden die bij de hierboven geciteerde regel staan,
van een heel andere orde: elpees (waar de letters dus uitgeschreven worden),
radars, lasers, sonartje.
Over gif's dan wel GIF's kan dus geen discussie bestaan.

> > Consistentie?
> 
> Met wat?

Met de twee regels erboven?
(In reply to comment #11)

> Ik denk dat je te veel in computermilieus vertoeft om hier een realistisch beeld
> te hebben.  90% van de Nederlandstaligen weet waarschijnlijk niet eens wat een
> gif is.

Dat valt op zich mee, maar technische achtergrond zal er inderdaad aan
bijdragen. :) Wat die 90% betreft, daar zit misschien wel wat in, maar toch denk
ik dat een afkorting met een klinker in het midden in de meeste gevallen ook
door niet-technische mensen voluit zal worden uitgesproken (vip-lounge,
bom-moeder, pac-file, doc-type etc.).

> En ok, die hoofdletters doen er niet veel toe, in dat verband verwijs
> ik naar een recent artikeltje in Onze Taal, dat ik jammer genoeg niet online kan
> terugvinden.  Hun advies was rond pdf: als je spreekt van een document, dan mag
> je spreken van een pdf, of een pdf'je, met kleine letters. Spreek je echter van
> het formaat, dan wordt het PDF, met grote.  Dat zou dus betekenendat we hier ook
> gif's moeten schrijven.

Ik kon het ook niet vinden, maar de gedachte hierachter is waarschijnlijk
dezelfde als bij radar en cd-rom etc., namelijk dat de afkorting gebruikt wordt
als een zelfstandige term, in dit geval het document. Aangezien de 2 voorkomens
van GIF in Mediadocument.properties ook wijzien op zelfstandig gebruik ben ik
dan geneigd om hier aan kleine letters te denken. Maar dat bedoelde jij
waarschijnlijk ook.

> Wat betreft de apostrof, is dit enigszins een
> aanduiding: http://www.onzetaal.nl/advies/gsmetje.html, en ook de verwijzing
> daarin.

Die tekst is me bekend, maar wordt m.i. in alle gevallen 'overruled' door het
citaat "Een afkorting die als woord wordt uitgesproken en op een medeklinker
eindigt, krijgt echter geen apostrof in het meervoud". (Zie
http://taalunieversum.org/taal/advies/vraag/1216/). Het is dus óf het een óf het
ander: niet als woord uitspreken maar wel een apostrof schrijven.
 
> Overigens zijn ook de voorbeelden die bij de hierboven geciteerde regel staan,
> van een heel andere orde: elpees (waar de letters dus uitgeschreven worden),
> radars, lasers, sonartje.
> Over gif's dan wel GIF's kan dus geen discussie bestaan.
> 

Dit begrijp ik niet. Gifs valt hier m.i. ook onder.

> 
> Met de twee regels erboven?

Het is juist omdat in de eerste twee regels 'het' ontbrak dat ik dit daarin heb
toegevoegd vanwege de aanwezigheid ervan in de originele tekst (en nog correct
zijn na vertaling) en gewenste consistentie. Wat lekker weglezen betreft (als je
dat ook bedoelde) vind ik zeker niet dat bij alledrie 'het' weglaten beter
leest. De noodzaak voor het behouden ervan lijkt me bovendien hoog omdat er
bewust sprake is van een vereist (en bekend) formaat. Je zou ook kunnen
vergelijken met '..in het juiste formaat', maar dat gaat eigenlijk niet op
vanwege het bijvoeglijk naamwoord daarin, al is de gelijkenis wel groot.

Overigens frappant dat ik niemand hoor over het correct zijn van 'is' (beter is
'staat in' of 'heeft'), wat ik er met enige tegenzin in heb gelaten. :)

(In reply to comment #12)

Om hier definitief een einde aan te maken: ik heb een vraag naar de
taaladviesdienst van Onze Taal gestuurd, omtrent waar je precies de grens legt
tussen letterwoorden en afkortingen.  Zullen we afspreken ons te houden aan
hetgeen zij antwoorden?
(In reply to comment #13)

Goed idee! En uiteraard houden we ons daaraan..

Was misschien ook handig geweest voor 'help-inhoud'? ;)
Dan moet je wel bij het stellen van de vraag uitleggen dat het belangrijk is dat
het deel Help wordt behouden. Anders komen ze met hulpinhoud als suggestie op de
proppen :).
Attached patch Diversen, o.a. 'sorteervolgorde' (obsolete) — — Splinter Review 
Wijziging in enkele access keys vanwege consistentie en/of niet functioneren en
grammaticale zaken. Ook gewijzigde termen met 'sorteervolgorde' in
bladwijzerbeheerder, mede vanwege lastig te plaatsen koppelteken.
(In reply to comment #15)
> Dan moet je wel bij het stellen van de vraag uitleggen dat het belangrijk is dat
> het deel Help wordt behouden. Anders komen ze met hulpinhoud als suggestie op de
> proppen :).

Inderdaad :) Het gaat dan meer om de vraag of zoiets als een eigennaam gezien
mag worden denk ik..
(In reply to comment #15)
> Dan moet je wel bij het stellen van de vraag uitleggen dat het belangrijk is dat
> het deel Help wordt behouden. Anders komen ze met hulpinhoud als suggestie op de
> proppen :).

Ik zal dit eens doen, maar ze hebben het daar heel druk, dus ik wil hier wel
zuinig op zijn, anders antwoorden ze niet meer.  Je kan als niet-lid ook tegen
betaling, maar dat vind ik dan weer net te ver gaan.
(In reply to comment #16)
> Created an attachment (id=187030) [edit]
> Diversen, o.a. 'sorteervolgorde'
> 
> Wijziging in enkele access keys vanwege consistentie en/of niet functioneren en
> grammaticale zaken. Ook gewijzigde termen met 'sorteervolgorde' in
> bladwijzerbeheerder, mede vanwege lastig te plaatsen koppelteken.

Ik vind het wat jammer dat er nu weer `&brandShortName;-vensters' in staat. 
Hoewel dit niet fout is, ziet het er wat vreemd uit.  Ik ben dan ook in de
hulpbestanden er overal `venster(s) van &brandShortName;' van aan het maken.

Alle andere vind ik top.

En wat is &#0187;? Dat is zoiets als >> klopt? Ik zie niet echt in waarom dat
daar hoort te staan (de tweede verandering)
(In reply to comment #19)
> Ik vind het wat jammer dat er nu weer `&brandShortName;-vensters' in staat. 
> Hoewel dit niet fout is, ziet het er wat vreemd uit.  Ik ben dan ook in de
> hulpbestanden er overal `venster(s) van &brandShortName;' van aan het maken.

Tja, het is denk ik niet erg om op die manier in enkele gevallen de term te
vermijden, maar om dat nu overal te doen..? Ik zou dit soort samenstellingen zo
laten als ze in de spreektaal ook nog zo worden gehanteerd; het wordt wat anders
bij langere termen als bijv. 'certificaatinstellingenvenster'. Vermijden kan
bovendien ook situaties als 'venster van xx van yy' opleveren, wat ook niet
alles is (2 x 'van'). 

> En wat is &#0187;? Dat is zoiets als >> klopt? Ik zie niet echt in waarom dat
> daar hoort te staan (de tweede verandering)

Klopt. Hoewel het waarschijnlijk zoiets is als een indicatie voor een procedure
die moet worden doorlopen vind ik het ook wat onwennig voor Firefox maar het
staat nu eenmaal (nog?) in de originele tekst. Hoop wel dat je daar ook steeds
naar kijkt?
Omdat Gebruikers van Internet Explorer er toch beter uitziet dan Internet
Explorer-gebruikers.  Is in de Help-bestanden ook al aangepast. (tenminste, de
patch moet nog goedgekeurd worden, zie bug 293223, comment 84)
(In reply to comment #21)
Sorry maar ik keur het af, in ieder geval voor het menu, omdat

- deze term nog langer wordt dan hij nu al is en daardoor onaantrekkelijker
wordt (menu ook te breed)
- termen in een menu naar mijn mening niet consistent hoeven te zijn met een
uitgeschreven term in de Help; wel het menu-item zelf natuurlijk maar om die te
gaan 'terugvertalen' is onlogisch
- zoals in comment #21 aangegeven, ik bang ben dat je soms te snel lijkt termen
te willen 'uitschrijven', enkel om het gebruik van een koppelteken te vermijden
terwijl daar niet altijd iets mis mee is (zoals hier)
- IE ook 'Voor Netscape-gebruikers' hanteert
- deze term in het menu al een tijdje is zoals ie is, ook na eerder overleg over
(juiste plaatsing van) het koppelteken

Het enige pluspuntje is misschien dat een 'Internet Explorer-gebruiker'
misschien wat 'verslaafder' (lees: IE-only-gebruiker) overkomt dan een
'gebruiker van Internet Explorer', maar dat is dan ook alles en m.i. niet genoeg
reden.
(In reply to comment #22)
> (In reply to comment #21)
> Sorry maar ik keur het af, in ieder geval voor het menu, omdat
> 
> - deze term nog langer wordt dan hij nu al is en daardoor onaantrekkelijker
> wordt (menu ook te breed)
> - termen in een menu naar mijn mening niet consistent hoeven te zijn met een
> uitgeschreven term in de Help; wel het menu-item zelf natuurlijk maar om die te
> gaan 'terugvertalen' is onlogisch
> - zoals in comment #21 aangegeven, ik bang ben dat je soms te snel lijkt termen
> te willen 'uitschrijven', enkel om het gebruik van een koppelteken te vermijden
> terwijl daar niet altijd iets mis mee is (zoals hier)

Ja, dat geef ik toe. Maar hier vind ik het net wél te verantwoorden, net omdat
je een samenstelling krijgt met een spatie in.

> - IE ook 'Voor Netscape-gebruikers' hanteert

Maar dat is maar één woord voor het streepje.  En dan nog, waarom zouden wij ons
laten beïnvloeden door wat IE doet?  (Ok beetje wel maar eigenheid enz enz.)

> - deze term in het menu al een tijdje is zoals ie is, ook na eerder overleg over
> (juiste plaatsing van) het koppelteken
> 
> Het enige pluspuntje is misschien dat een 'Internet Explorer-gebruiker'
> misschien wat 'verslaafder' (lees: IE-only-gebruiker) overkomt dan een
> 'gebruiker van Internet Explorer', maar dat is dan ook alles en m.i. niet genoeg
> reden.

Nu ja, ik kan ermee leven hoor.  Nog andere meningen?  Anders moet ik snel de
patch in bug 293223 gaan aanpassen.
Attached patch woordvolgorde iets natuurlijker (obsolete) — — Splinter Review 
Ik vind dit een natuurlijkere woordvolgorde.  Ook in de help-bestanden heb ik
het zo vertaald...  (Er stond daar nog TODO, vandaar)
Attached file het is dus gifs — 
Blijkbaar is het toch gifs.  Met kleine letters en s eraan vast.  Dat is dan
gesetteld...
Attached patch sites -> websites, kleinigheden (obsolete) — — Splinter Review 
Ik dacht dat site over het algemeen met website werd vertaald. Verder sluit
Sierletter beter aan bij de realiteit en de praktijk (zie
news://news.gmane.org:119/17068.9278.220421.766707@ordesa.local en de rest van
de thread)
Proxyinstellingen bekt beter.
We hadden elders toegestane websites vervangen, dus hier ook.  Verder spreek je
standaardlettertype met ייn klemtoon uit, dus moet het aan elkaar.
(In reply to comment #9)
> (From update of attachment 186796 [details] [diff] [review] [edit])
> patch is toegepast
> 
> ik heb 2 veranderingen aan de patch gemaakt:
> - Gif's 

Dit zou dus nog aangepast moeten worden!
Attached patch ook veelvoorkomend aan elkaar (obsolete) — — Splinter Review 
Hetzelfde als de vorige, maar in dezelfde lijn als standaardlettertype hoort
ook veelvoorkomende hier aan elkaar.  Anders lijkt het alsof je veel (in
aantal) voorkomende ergernissen uitschakelt...
Attachment #187574 - Attachment is obsolete: true
Tekensets heeft in dat venstertje niks te zoeken, en de breedte moet breder,
omdat de n van het keuzemenu wegvalt.

de tekst bij Caret Browsing klopte helemaal niet met de Engelse versie en met
de omschrijving in de help.

het is Actie veranderen in het venster dat dit venster oproept...
Attached patch gebruik makend, streepjes (obsolete) — — Splinter Review 
enkele streepjes en gebruik maken is in twee woorden
Attached patch streepjes (obsolete) — — Splinter Review 
een koppelstreepje
(In reply to comment #31)
Gifs: sorry.. ;) Uitgebreid antwoord trouwens, petje af voor ze.

Patches: het meeste lijkt me wel OK. Of overal website moest worden gebruikt was
me niet duidelijk maar is m.b.t. consistentie misschien wel goed. Alleen bij
useTypeAheadFind.label, moet daarin 'Beginnen' niet behouden blijven i.v.m.
consistent gebruik van infinitief? moveSystemCaret.label is ook verbeterd, maar
ik vraag me af of het nog nodig wordt gevonden en/of mogelijk is om het 'allow'
erin terug te laten komen.

Het eerste koppelteken bij 'OCSP-service-URL' had ik onlangs met opzet
weggelaten omdat ik het op dat moment zag als een woordcombinatie (mede door
klemtoon) waarbij het deel 'OCSP' dan los komt te staan, terwijl ik ze er eerder
in had gezet. Dat dit juist is wil ik daarmee niet zeggen, het is toch een
normale samenstelling. Met 'gebruikmakend' aan elkaar geschreven echter is
volgens de nieuwe spelling niks mis. Daarom is dit onlangs in dezelfde patch
gewijzigd naar deze vorm en hetzelfde moet eigenlijk op enkele andere plaatsen
ook nog gebeuren.

Uit nieuwsgierigheid: is het de 'n' van 'voegen' die bij jou wegvalt? Hier is
dat niet zo maar dat kan te maken hebben met resolutie (ik had hem onlangs zo
breed gemaakt als net nodig was). En doelde je met 'proxyinstellingen bekt
beter' op de ook in attachment 187431 [details] [diff] [review] voorgestelde wijziging (waarmee die dus
overbodig wordt)?

(In reply to comment #33)
> (In reply to comment #31)
> Gifs: sorry.. ;) Uitgebreid antwoord trouwens, petje af voor ze.

Waarom sorry?  We hadden het allebei een beetje fout en een beetje goed...

> Patches: het meeste lijkt me wel OK. Of overal website moest worden gebruikt was
> me niet duidelijk maar is m.b.t. consistentie misschien wel goed. 

Dat is ook de reden.  Vooral in de documentatie (Firefox gebruiken:
using_firebird.xhtml en prefs.xhtml) valt het een beetje op in de bespreking van
de knoppen en zo.

> Alleen bij
> useTypeAheadFind.label, moet daarin 'Beginnen' niet behouden blijven i.v.m.
> consistent gebruik van infinitief? 

Ik ben me niet bewust vqn (tss, overschakelen tussen azerty en qwerty, altijd
leuk) een richtlijn hieromtrent, maar als die er is, dan hoor ik het graag, en
het wou hier inderdaad geen probleem wijn om er beginnen van te maken.

> moveSystemCaret.label is ook verbeterd, maar
> ik vraag me af of het nog nodig wordt gevonden en/of mogelijk is om het 'allow'
> erin terug te laten komen.

Vind ik niet echt nodig, temeer omdat ik het in het Engels ook nogal ongelukkig
geformuleerd vind.  Wat heeft het uiteindelijk met toestaan te maken?  Het is
gewoon een functie die je al dan niet inschakelt.

> Het eerste koppelteken bij 'OCSP-service-URL' had ik onlangs met opzet
> weggelaten omdat ik het op dat moment zag als een woordcombinatie (mede door
> klemtoon) waarbij het deel 'OCSP' dan los komt te staan, terwijl ik ze er eerder
> in had gezet. Dat dit juist is wil ik daarmee niet zeggen, het is toch een
> normale samenstelling. 

Ja, het ziet er wat raar uit, maar is heel logisch: er bestaat een dienst met de
naam OCSP; een aanbieder van die dienst is een OCSP-service, en als die service
op een URL te vinden is, dan is dat een OCSP-service-URL. Geen speld tussen te
krijgen.

> Met 'gebruikmakend' aan elkaar geschreven echter is
> volgens de nieuwe spelling niks mis. Daarom is dit onlangs in dezelfde patch
> gewijzigd naar deze vorm en hetzelfde moet eigenlijk op enkele andere plaatsen
> ook nog gebeuren.

Hm, dat is inderdaad discuteerbaar.  Ik herinner me een artiekl in Onze Taal
rond dit thema, dat meer en meer werkwoordgroepen als één werkwoord gewien
worden (gebruikmaken, tewerkstellen, bekendmaken...°  Nu ja, je schijnt gelijk
te hebben: http://www.onzetaal.nl/advies/gebruik.htm

> Uit nieuwsgierigheid: is het de 'n' van 'voegen' die bij jou wegvalt? Hier is
> dat niet zo maar dat kan te maken hebben met resolutie (ik had hem onlangs zo
> breed gemaakt als net nodig was). 

Inderdaad.  Ook in de 1.0.4 die ik nu voor me heb trouwens. Met 1024x768.

> En doelde je met 'proxyinstellingen bekt
> beter' op de ook in attachment 187431 [details] [diff] [review] [edit] voorgestelde wijziging (waarmee
die dus
> overbodig wordt)?

Ah ja, niet op gelet.  Ik maak 187431 dan obsolete ok?
Attachment #187431 - Attachment is obsolete: true
(In reply to comment #34)
> > Met 'gebruikmakend' aan elkaar geschreven echter is
> > volgens de nieuwe spelling niks mis. Daarom is dit onlangs in dezelfde patch
> > gewijzigd naar deze vorm en hetzelfde moet eigenlijk op enkele andere plaatsen
> > ook nog gebeuren.
> 
> Hm, dat is inderdaad discuteerbaar.  Ik herinner me een artiekl in Onze Taal
> rond dit thema, dat meer en meer werkwoordgroepen als één werkwoord gewien
> worden (gebruikmaken, tewerkstellen, bekendmaken...°  Nu ja, je schijnt gelijk
> te hebben: http://www.onzetaal.nl/advies/gebruik.htm

Maar zie anderzijds ook http://www.onzetaal.nl/advies/gebruikmaken.html...  Dit
is overigens een goede eerste test in twijfelgevallen (naast het GB natuurlijk)
Attached patch Allerlei kleinigheden (obsolete) — — Splinter Review 

    
    

    
  
Ziet er zeer goed uit, items is idd beter dan elementen.

Maar: - in tabbed-browsing.xhtml mag het streepje in context-menu nog weg (pas
echter op, dit wordt in de bug rond de help fan FF1.1 helemaal bijgewerkt, dat
wal tot een clash leiden.) Zie bug 293223.  Ik denk dat het beter is alle
patches rond helpbestanden daar apart te houden, nu doen we dubbel werk.  Ofwel
daar eens een gerichte zoektocht naar `links' houden, maar misschien eerst
afwachten wat er met al mijn patches gebeurt.  (commentaar overigens zeer welkom).
- in newserver.dtd: server-misconfiguratie ook nog zonder streepje; maar liever
nog herformuleren.
- in viewSource.dtd: syntaxis-kleurcodes in principe ook nog zonder streepje,
maar goed.
- in welcome.xhtml: Klik de Startknop aan -> Klik op de startknop.

    
    

    
  
(In reply to comment #37)
Contextmenu: ok, blijf ik dan even vanaf.

Links: als het goed is is alles er al uit op 2 na, dit waren de laatste. (1
volgt nog, de ander moet zo blijven).

Server-misconfiguratie: streepje opzettelijk behouden vanwege leesbaarheid.
Servermisconfiguratie leest moeilijker (vnl. vanwege 'vermis') maar het zou evt.
'misconfiguratie op server' kunnen worden, al pleit ik er niet voor.

Syntaxis-kleurcodes: ook met opzet behouden vanwege leesbaarheid in 'vreemde'
gelegenheidssamenstelling), al is deze minder erg.
 
Klik op de startknop: was me opgevallen maar nog even zo gelaten omdat er
globaal meer van dit soort inconsistente formuleringen zijn (klik (op) .. / klik
.. aan). Lijken nu echter alleen in dit bestand te zitten.

P.S. Is Tim Maks met vakantie? ;)


    
    

    
  


  
Ik ben niet zeker of de ë's er goed doorkomen, moet ik die op een speciale
manier ingeven, of ligt dat aan cvs?

Commentaar welkom, ik ben niet echt vertrouwd met de terminologie.  I.h.b.
omtrent 'important'

    
    

    
  
(In reply to comment #39)
Ziet er op het eerste gezicht goed uit (en ik kan hem schrappen ;)). Wat betreft
terminologie zal ik hem later ook nog wel nalopen.

De ë maak je in een in een .properties-bestand door \u00EB en vergelijkbare
unicode-notaties zijn er voor soortgelijke karakters. Voor .dtd-bestanden gaat
het anders; ik heb begrepen dat een UTF-8-geschikte editor ze vanzelf aanmaakt,
maar kopieer en plak ze tot nu toe steeds met notepad. :) Zie ook
http://www.mozilla.org/projects/l10n/mlp_what2.html.


    
    

    
  

      
      
      
      

        Attached patch
          
          
        in de map updates (obsolete)
        — 
          — Splinter Review
      

    


  
enkele wijzigingen, enkele nieuwe dingen...

    
    

    
  

      
      
      
      

        Attached patch
          
          
        safari-update (obsolete)
        — 
          — Splinter Review
      

    


  
zie bug 236300

    
    

    
  

      
      
      
      

        Attached patch
          
          
        counter toegevoegd (obsolete)
        — 
          — Splinter Review
      

    


  
zie bug 201264

Ik wou dit samen doen met de vorige, maar het lukt me voorlopig nog niet om
specifieke bestanden in verschillende mappen te selecteren om een patch te
maken (er stond nog ייn gewijzigd bestand tussen dat hier niet thuishoorde). 
Iemand suggesties hoe dit wel kan (er is een feature request hierrond in
Eclipse, mqqr dqt is blijkbaat nog niet in de nieuwe 3.1 verwerkt) (gr qwerty)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Wijzigingen n.a.v. nieuwigheden (obsolete)
        — 
          — Splinter Review
      

    


  
Wijzigingen n.a.v. nieuwigheden, o.a. updates.dtd, updates.properties en
advanced.dtd. Ook die uit attachment 187030 [details] [diff] [review] zijn erin verwerkt.

        Attachment #187030 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #40)
> (In reply to comment #39)
> Ziet er op het eerste gezicht goed uit (en ik kan hem schrappen ;)). Wat betreft
> terminologie zal ik hem later ook nog wel nalopen.
> 
> De ë maak je in een in een .properties-bestand door \u00EB en vergelijkbare
> unicode-notaties zijn er voor soortgelijke karakters. Voor .dtd-bestanden gaat
> het anders; ik heb begrepen dat een UTF-8-geschikte editor ze vanzelf aanmaakt,
> maar kopieer en plak ze tot nu toe steeds met notepad. :) Zie ook
> http://www.mozilla.org/projects/l10n/mlp_what2.html.

Ok sorry, dan moet de toepasser hier maar even snel find-replace ë met \u00EB doen.

    
    

    
  

      
      
      
      

        Attached file
          
        mozapps\preferences\update.dtd (obsolete)
        — 
      

    


  
Straks waarschijnlijk nodig.

    
    

    
  

      
      
      
      

        Attached file
          
        mozapps\update\history.dtd (obsolete)
        — 
      

    


  
Idem.

    
    

    
  
(In reply to comment #44)
> Created an attachment (id=188153) [edit]
> Wijzigingen n.a.v. nieuwigheden
> 
> Wijzigingen n.a.v. nieuwigheden, o.a. updates.dtd, updates.properties en
> advanced.dtd. Ook die uit attachment 187030 [details] [diff] [review] [edit] zijn erin verwerkt.

<!ENTITY certselect.auto              "Automatisch een selecteren">
hiervan zou ik `ייn' maken

-<!ENTITY  downloading.title               "Update downloaden">
+<!ENTITY  downloading.title               "Downloaden van update">
vond ik vroeger beter

Ik vrees trouwens dat we een paar dingen dubbel gedaan hebben in dit bestand,
zie mijn attachment 188146 [details] [diff] [review]; ik ben zelfs nog wat strenger geweest (pauZe enz.)

-downloadingPrefix=Downloaden %S...
+downloadingPrefix=Downloaden van %S...
beter: %S downloaden...

Ik vind `(neem contact op met) us _systeem_beheerder' toch duidelijker.

Proxyserververbinding: ייn woord (heb ik hierboven ook fout :-$

Je hebt een keer "(Het toepassen van de patch mislukte)" en een keer "(Patch
toepassen mislukt)" dat moet tweemaal hetzelfde (laatste als je het mij vraagt)

    
    

    
  
(In reply to comment #47)
> Created an attachment (id=188155) [edit]
> mozapps\update\history.dtd
> 
> Idem.

kan je die laatste twee eens als patch insturen, en niet als octet-stream?

    
    

    
  
(In reply to comment #49)
> (In reply to comment #47)
> > Created an attachment (id=188155) [edit] [edit]
> > mozapps\update\history.dtd
> > 
> > Idem.
> 
> kan je die laatste twee eens als patch insturen, en niet als octet-stream?

Ok, geen patch, maar dan minstens tekstbestand.  Zien er wel ok uit verder.

    
    

    
  


  
Dezelfde als attachment 188153 [details] [diff] [review] maar met enige aanpassingen.

(In reply to comment #48)
> <!ENTITY certselect.auto		"Automatisch een selecteren">
> hiervan zou ik `één' maken

Was er al bang voor. :) How about 'Er automatisch een selecteren'? Wil graag
gebruik van 'één' vermijden, omdat dit m.i. te veel accent legt op het aantal.

> -<!ENTITY  downloading.title		     "Update downloaden">
> +<!ENTITY  downloading.title		     "Downloaden van update">
> vond ik vroeger beter

Heb dit gelijkgetrokken n.a.v. 'Controleren op updates'; in beide gevallen gaat
het om venstertitels, waaronder een soortgelijke zin volgt. Vandaar mijn
voorkeur om beide titels op de andere manier te schrijven, maar als
downloading.title per sé zo moet blijven zal de andere moeten veranderen.

> Ik vrees trouwens dat we een paar dingen dubbel gedaan hebben in dit bestand,

> zie mijn attachment 188146 [details] [diff] [review] [edit]; ik ben zelfs nog wat strenger geweest
(pauZe enz.)

Yep.. Op zich had je misschien beter even kunnen wachten aangezien er nog iets
aan de updatebestanden kon wijzigen (clash?) en het had je werk bespaard. :)

'Akkoord' en 'Pauze' zijn goed gezien maar de laatste moet vermoedelijk zelfs
'pauzeren' zijn. 'At' betekent hier ook 'met', 'verdeler' ben ik niet bepaald
voor (die zitten hier in een auto en verkopen zeker geen software :) ),
'update-server' hoeft geen deelstreepje, behalve hooguit voor leesbaarheid en
'alstublieft' wordt als het even kan vermeden.

> -downloadingPrefix=Downloaden %S...
> +downloadingPrefix=Downloaden van %S...
> beter: %S downloaden...
> 

Tja.. Als men bij een engelse 'present' (ing-vorm) redeneert vanuit de vraag
'Bezig met <wat>?' en dit antwoord ook achter 'Bezig met' wil kunnen plaatsen
dan is 'Downloaden van %S...' wel in orde en gelijk aan enkele andere gevallen.
Maar blijkbaar komen er ook gevallen voor met het werkwoord achteraan, evenals
termen met 'aan het' erin dus dit is niet erg consistent. Bestaat hiervoor een
eenduidige voorkeur?

> 
> Ik vind `(neem contact op met) us _systeem_beheerder' toch duidelijker.
> 

Hmja, letterlijk is een administrator een beheerder, anders was er sprake van
'system administrator', wat op sommige plaatsen wel wordt gebruikt. 'Contact
opnemen' is hier wel beter, ging uit van 'consult' elders.

> Proxyserververbinding: één woord (heb ik hierboven ook fout :-$
>

Officieel wel maar je zult begrijpen dat dit vanwege leesbaarheid is gedaan
(..verver..) en dus is toegestaan. Dacht ook nog aan 'Verbinding met
proxyserver', dat zou ook meer duidelijkheid geven en klopt taalkundig gezien
beter.

> Je hebt een keer "(Het toepassen van de patch mislukte)" en een keer "(Patch
> toepassen mislukt)" dat moet tweemaal hetzelfde (laatste als je het mij
vraagt)

Goed kijken. ;)

    
  

        Attachment #188153 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 188146 [details] [diff] [review]
in de map updates

(In reply to comment #51)
> Created an attachment (id=188178) [edit]
> Wijzigingen n.a.v. nieuwigheden, v2
> 
> Dezelfde als attachment 188153 [details] [diff] [review] [edit] maar met enige aanpassingen.
> 
> (In reply to comment #48)
> > <!ENTITY certselect.auto		"Automatisch een selecteren">
> > hiervan zou ik `één' maken
> 
> Was er al bang voor. :) How about 'Er automatisch een selecteren'? Wil graag
> gebruik van 'één' vermijden, omdat dit m.i. te veel accent legt op het aantal.

Vind ik ook.  Goede oplossing.

> > -<!ENTITY  downloading.title		     "Update downloaden">
> > +<!ENTITY  downloading.title		     "Downloaden van update">
> > vond ik vroeger beter
> 
> Heb dit gelijkgetrokken n.a.v. 'Controleren op updates'; in beide gevallen gaat
> het om venstertitels, waaronder een soortgelijke zin volgt. Vandaar mijn
> voorkeur om beide titels op de andere manier te schrijven, maar als
> downloading.title per sé zo moet blijven zal de andere moeten veranderen.

Het is die 'van' die wat on-Nederlands aandoet.  Kan natuurlijk wel, maar ander
klinkt beter (imho)

> > Ik vrees trouwens dat we een paar dingen dubbel gedaan hebben in dit bestand,
> 
> > zie mijn attachment 188146 [details] [diff] [review] [edit] [edit]; ik ben zelfs nog wat strenger geweest
> (pauZe enz.)
> 
> Yep.. Op zich had je misschien beter even kunnen wachten aangezien er nog iets
> aan de updatebestanden kon wijzigen (clash?) en het had je werk bespaard. :)
> 
> 'Akkoord' en 'Pauze' zijn goed gezien maar de laatste moet vermoedelijk zelfs
> 'pauzeren' zijn. 'At' betekent hier ook 'met', 'verdeler' ben ik niet bepaald
> voor (die zitten hier in een auto en verkopen zeker geen software :) ),
> 'update-server' hoeft geen deelstreepje, behalve hooguit voor leesbaarheid en
> 'alstublieft' wordt als het even kan vermeden.

Ik stel voor dat jij er een definitieve van maakt.  Verdeler kan voor mij om
het even wat leveren, maar distributeur klinkt zo gemaakt... nu ja, kan geen
betere bedenken.

> > -downloadingPrefix=Downloaden %S...
> > +downloadingPrefix=Downloaden van %S...
> > beter: %S downloaden...
> 
> Tja.. Als men bij een engelse 'present' (ing-vorm) redeneert vanuit de vraag
> 'Bezig met <wat>?' en dit antwoord ook achter 'Bezig met' wil kunnen plaatsen
> dan is 'Downloaden van %S...' wel in orde en gelijk aan enkele andere gevallen.
> Maar blijkbaar komen er ook gevallen voor met het werkwoord achteraan, evenals
> termen met 'aan het' erin dus dit is niet erg consistent. Bestaat hiervoor een
> eenduidige voorkeur?

Gewoon kiezen wat het beste klinkt, als je het mij vraagt.  Hier zie ik geen
reden voor 'consistentie', het is tenslotte gewoon een manier van zeggen die
verschilt met het Engels.

> > Ik vind `(neem contact op met) us _systeem_beheerder' toch duidelijker.
> 
> Hmja, letterlijk is een administrator een beheerder, anders was er sprake van
> 'system administrator', wat op sommige plaatsen wel wordt gebruikt. 'Contact
> opnemen' is hier wel beter, ging uit van 'consult' elders.

Laten we zeggen dat het Engels daar in de fout gaat.  Beheerder, daar kan ik me
niks bij voorstellen.  Het moet toch niet altijd letterlijk zijn als de
betekenis duidelijk is?

> > Proxyserververbinding: één woord (heb ik hierboven ook fout :-$
> 
> Officieel wel maar je zult begrijpen dat dit vanwege leesbaarheid is gedaan
> (..verver..) en dus is toegestaan. Dacht ook nog aan 'Verbinding met
> proxyserver', dat zou ook meer duidelijkheid geven en klopt taalkundig gezien
> beter.

Doen!

> > Je hebt een keer "(Het toepassen van de patch mislukte)" en een keer "(Patch
> > toepassen mislukt)" dat moet tweemaal hetzelfde (laatste als je het mij
> vraagt)
> 
> Goed kijken. ;)

Oeps, sorry.

Nog een nieuwe opmerking: 
<!ENTITY  verificationFailedText.label	  "&brandShortName; was niet in staat
om de integriteit van de incrementele update die het heeft gedownload te
controleren, dus het downloadt nu het volledige updatepakket.">
Ik zou hier het gebruik van 'het' verwijzend naar Firefox vermijden.  Ten
eerste omdat het hier naar mijn aanvoelen 'hij' zou moeten zijn, en ten tweede
omdat het beter klinkt passief, zoals in mijn patch: 
<!ENTITY  verificationFailedText.label	  "&brandShortName; was niet in staat
de integriteit van de incrementele update die gedownload werd te verifiëren,
dus wordt nu het complete updatepakket gedownload.">

Ik maak mijn patch obsolete.

        Attachment #188146 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #39)
> Created an attachment (id=188143) [edit]
> Zo goed als volledig nieuw vertaald
> 
> Ik ben niet zeker of de ë's er goed doorkomen, moet ik die op een speciale
> manier ingeven, of ligt dat aan cvs?

Alleen in .properties files. De rest wordt allemaal ingelezen als UTF-8. Dat het
in de diff van bugzilla anders wordt weergegeven is omdat Bugzilla niet op
encodings let, en zelf in Latin-1 werkt (waarom weet ik ook niet).


~Grauw

    
    

    
  

      
      
      
      

        Attached patch
          
          
        update van advanced.dtd (obsolete)
        — 
          — Splinter Review
      

    


  
n.a.v. veranderingen in Engelse tekst.

Zie ook volgende attachment.

    
    

    
  


  
Ook nieuw toegevoegd in Engels.

    
    

    
  
De wijzigingen van attachment 188234 [details] [diff] [review] zitten als het goed is al in attachment
188178 [details] [diff] [review] verwerkt. Attachment 188235 [details] lijkt me wat te klein en zou attachment
188154 [details] moeten zijn.

    
    

    
  
(In reply to comment #56)
> De wijzigingen van attachment 188234 [details] [diff] [review] [edit] zitten als het goed is al in
attachment
> 188178 [edit] verwerkt. Attachment 188235 [details] [edit] lijkt me wat te klein en zou
attachment
> 188154 [edit] moeten zijn.

Maar waarom zit deze laatste dan onder mozapps/preferences?  Dit is niet zo in
de Engelse versie.  Hm, maar er schijnt wel vaker een verschil te zijn.  Wat is
hier het systeem?

    
    

    
  
(In reply to comment #57)
Omdat ie onlangs daarheen is verplaatst (bug 269483). Wat bedoel je precies met
'de engelse versie'? Aangezien update.dtd nog niet in de NL cvs zit en 188265 zo
kort is weet ik niet waar je die vandaan hebt gehaald?

Ik krijg een beetje de indruk dat je niet altijd de laatste NL cvs-versie en
en-US trunk gebruikt, ook doordat wijzigingen van attachment 188147 [details] [diff] [review] en 188148 al
in de cvs zitten..

    
    

    
  
(In reply to comment #58)
> (In reply to comment #57)
> Omdat ie onlangs daarheen is verplaatst (bug 269483). Wat bedoel je precies met
> 'de engelse versie'? Aangezien update.dtd nog niet in de NL cvs zit en 188265 zo
> kort is weet ik niet waar je die vandaan hebt gehaald?

Hm, je hebt gelijk.

> Ik krijg een beetje de indruk dat je niet altijd de laatste NL cvs-versie en
> en-US trunk gebruikt, ook doordat wijzigingen van attachment 188147 [details] [diff] [review] [edit] en
188148 al
> in de cvs zitten..

Ik gebruik
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=mozilla%2Fbrowser%2Flocales%2Fen-US%2F%2Cmozilla%2Fdom%2Flocales%2Fen-US%2F%2Cmozilla%2Fextensions%2Freporter%2Flocales%2Fen-US%2F%2Cmozilla%2Fnetwork%2Flocales%2Fen-US%2F%2Cmozilla%2Fsecurity%2Fmanager%2Flocales%2Fen-US%2F%2Cmozilla%2Ftoolkit%2Flocales%2Fen-US%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=month&mindate=&maxdate=&cvsroot=%2Fcvsroot,
maar ik zie dat ik al te ver naar onderen aan het kijken was...

Sorry.  Ik zal me nu even op de resterende helpbestanden concentreren, en
binnenkort op vakantie, dus dan heb je even geen last meer van me ;-)

    
    

    
  
Even een vraagje: waarom gebruiken we client en niet cliënt?  O.a. in
glossary.xhtml.  Ik vind niks in de mozillanl woordenlijst, maar in de kde-lijst
staat cliënt met trema.  In de combinatie client-server is er iets voor het
Engelse woord te zeggen, maar ik zie geen probleem in de `ingeburgerde' versie
cliënt.

    
    

    
  
(In reply to comment #60)
> Even een vraagje: waarom gebruiken we client en niet cliënt?  O.a. in
> glossary.xhtml.  Ik vind niks in de mozillanl woordenlijst, maar in de kde-lijst
> staat cliënt met trema.  In de combinatie client-server is er iets voor het
> Engelse woord te zeggen, maar ik zie geen probleem in de `ingeburgerde' versie
> cliënt.

Omdat het het Engelse ‘client’ is wat wij hier gebruiken en niet het Nederlandse
‘cliënt’. De uitspraak is ook op zijn Engels (klaient). Zoals je zelf al zegt is
in de combinatie client-server wat voor het gebruik van het Engels te zeggen, en
dat is ook precies waarom het Engels gebruikt word. Ook als er niet in de nabije
omgeving het woord ‘server’ staat gaat het toch om hetzelfde woord en dezelfde
toepassing daarvan.

Het Nederlandse woord cliënt heb ik nog nooit in de zin van ‘user agent’ die
verbindt met een server gebruikt zien worden. Een cliënt van een advocaat
natuurlijk wel :).


~Grauw

    
    

    
  
(Overigens ben ik op zich niet bijzonder tegen een verandering van client ->
cliënt, het is mij om het even.)

~Grauw

    
  

        Attachment #188235 -
        Attachment is obsolete: true

    
  

        Attachment #188234 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 188147 [details] [diff] [review]
safari-update

is op 3-7 verandert in de cvs

        Attachment #188147 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 188148 [details] [diff] [review]
counter toegevoegd

is op 3-7 toegevoegd aan de cvs

        Attachment #188148 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 188154 [details]
mozapps\preferences\update.dtd

vertaling toegevoegd

        Attachment #188154 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 188155 [details]
mozapps\update\history.dtd

andere versie is reeds in de cvs.

        Attachment #188155 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 187573 [details] [diff] [review]
sites -> websites, kleinigheden

patch toegepast

        Attachment #187573 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 187575 [details] [diff] [review]
ook veelvoorkomend aan elkaar

patch toegepast

        Attachment #187575 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 187585 [details] [diff] [review]
enkele inconsistenties en fouten verbeterd

patch toegepast

        Attachment #187585 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 188155 [details]
mozapps\update\history.dtd

oude versie is toch vervangen voor deze versie

    
    

    
  
Comment on attachment 187280 [details] [diff] [review]
IE-gebruikers wordt gebruikers van iE

naar mijn mening moet het in het menu gewoon blijven zoals het is.

        Attachment #187280 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 187586 [details] [diff] [review]
gebruik makend, streepjes

alleen <!ENTITY certOCSP.label		     "OCSP alleen gebruiken om
certificaten te controleren die een OCSP-service-URL specificeren"> toegepast

        Attachment #187586 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 187587 [details] [diff] [review]
streepjes

toegepast

        Attachment #187587 -
        Attachment is obsolete: true

    
    

    
  
welkom terug :)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Allerlei kleinigheden, aangepast (obsolete)
        — 
          — Splinter Review
      

    


  
Kleine aanpassing, en wijzigingen voor helpbestanden naar bug 2932233.

        Attachment #187977 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Allerlei kleinigheden, aangepast (obsolete)
        — 
          — Splinter Review
      

    


  
Nu volledig..

        Attachment #189288 -
        Attachment is obsolete: true

    
    

    
  


  
Aangepast en enkele zaken toegevoegd.

        Attachment #188178 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Allerlei kleinigheden, aangepast (obsolete)
        — 
          — Splinter Review
      

    


  
Aangepast vanwege wijziging in extensions.properties.

        Attachment #189293 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Css.properties (obsolete)
        — 
          — Splinter Review
      

    


  
Css.properties van att 188143 met aanpassingen naar 'vrijgegeven', 'onbekend',
'regelsets' en ë -> \u00EB.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Allerlei kleinigheden, aangepast (obsolete)
        — 
          — Splinter Review
      

    


  
Bijgewerkt vanwege wijziging in extensions.properties en correctie op
Mozbrowzer-forum.

    
  

        Attachment #189529 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 188143 [details] [diff] [review]
Zo goed als volledig nieuw vertaald

volgesn mij is deze patch vervangen door patch 189530

        Attachment #188143 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 189530 [details] [diff] [review]
Css.properties

toegepast

        Attachment #189530 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 189324 [details] [diff] [review]
Wijzigingen n.a.v. nieuwigheden, v3

patch toegepast

        Attachment #189324 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 189754 [details] [diff] [review]
Allerlei kleinigheden, aangepast

patch toegepast

        Attachment #189754 -
        Attachment is obsolete: true

    
    

    
  


  
Ik ontdekte dat er in de sanitizefunctie en de privacy-opties verschillende
termen gebruikt worden. Deze patch trekt dat recht. Ik hierbij
navigatiegeschiedenis gekozen, die al in de privacy-opties gebruikt werd, boven
bladergeschiedenis.
Daarnaast nog 2 meervouden, Cursornavigatie zonder hoofdletter en
addons.mozilla.org ipv update.mozilla.org.

    
    

    
  
Comment on attachment 190176 [details] [diff] [review]
Inconsistenties in Sanitize en andere kleine dingen

Toegepast

        Attachment #190176 -
        Attachment is obsolete: true

    
    

    
  


  

    
    

    
  
Comment on attachment 190955 [details] [diff] [review]
Foutje in itemnaam in content.dtd

patch toegepast, dank je

        Attachment #190955 -
        Attachment is obsolete: true

    
    

    
  


  
In netError.dtd worden quotes aangegeven met [q] en [/q] (dus niet met &quot;)
Anders is er geen tekst zichtbaar, zonde van dat mooie scherm.

    
    

    
  
(In reply to comment #89)
> Created an attachment (id=191311) [edit]
> Quotes worden gemarkeerd met [q] en [/q]
> 
> In netError.dtd worden quotes aangegeven met [q] en [/q] (dus niet met &quot;)
> Anders is er geen tekst zichtbaar, zonde van dat mooie scherm.

Nu nog de andere taal ook mooier maken: veelvoorkomend, geformeerd (?),... en
het resterende Engels vertalen...  Maar anders doe ik dat wel eens.

    
    

    
  
Comment on attachment 191311 [details] [diff] [review]
Quotes worden gemarkeerd met [q] en [/q]

Jullie zijn me net voor; ik wilde vandaag een verzoek hier plaatsen of iemand
naar dit bestand wilt gaan kijken. Er is namelijk veel verandert in de engelse
tekst.

ik heb deze patch al wel toegepast en ik hoop dus dat er snel een nieuwe versie
komt van dit bestand.

Bedankt

        Attachment #191311 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        neterror.dtd (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 191324 [details] [diff] [review]
neterror.dtd

patch toegepast

Bedankt

        Attachment #191324 -
        Attachment is obsolete: true

    
    

    
  


  
de voorbeeldbestanden in profile/chrome, vertaald.  De patch ziet er vreemd
uit, vind ik, maar geen structurele wijzigingen.

    
    

    
  


  
Verschillende kleine aanpassingen, voornamelijk accesskeys. Sommige accesskeys
waren niet juist, andere onlogisch.

    
    

    
  
(In reply to comment #95)
> Created an attachment (id=191883) [edit]
> Kleine foutjes (voornamelijk accesskeys)
> 
> Verschillende kleine aanpassingen, voornamelijk accesskeys. Sommige accesskeys
> waren niet juist, andere onlogisch.

Ik ben niet zo voor etc...: dat is dubbelop!  En er is het mooiere enz.
Verder bon.

    
    

    
  
(In reply to comment #95)
> Created an attachment (id=191883) [edit]
> Kleine foutjes (voornamelijk accesskeys)
> 
> Verschillende kleine aanpassingen, voornamelijk accesskeys. Sommige accesskeys
> waren niet juist, andere onlogisch.

Index: nl/browser/chrome/browser/sanitize.dtd
Index: nl/browser/chrome/browser/preferences/content.dtd
===================================================================
ok


Index: nl/browser/chrome/browser/preferences/privacy.dtd
===================================================================
-<!ENTITY  privacy.intro               "Terwijl u over het web navigeert,
bewaart &brandShortName; informatie over waar u bent geweest, wat u gedaan heeft
etc. in de volgende gebieden:">
+<!ENTITY  privacy.intro               "Terwijl u over het web navigeert,
bewaart &brandShortName; informatie over waar u bent geweest, wat u heeft
gedaan, etc... In de volgende gebieden wordt informatie opgeslagen:">

Ik vind 'wat u heeft gedaan' nog wel een verbetering, maar de komma erna, de ...
en de nieuwe zin niet. Naast het te veel afwijken van het Engelse tekst wordt
het wat te langgerekt en impliceert het boze (hoofd)bedoelingen van de browser.

-<!ENTITY  savedPasswords.intro        "&brandShortName; kan de inloginformatie
voor webpagina’s in de wachtwoordenbeheerder bijhouden zodat u uw inlogdetails
niet bij elk bezoek opnieuw hoeft in te voeren.">
+<!ENTITY  savedPasswords.intro        "&brandShortName; kan de inloginformatie
voor webpagina’s in de wachtwoordenbeheerder bijhouden, zodat u uw
inlogdetails niet bij elk bezoek opnieuw hoeft in te voeren.">

Met de komma ben ik het wel eens. Ik zie ook dat je 'details' hier behoudt en in
TB vervangt door 'gegevens'? Oeps.., in de TB-patch wijzig je ditzelfde
(browser)bestand. Misschien dat die wijzigingen zijn bestemd voor
nl/mail/.../privacy.dtd? Ik heb zelf geen bezwaar tegen 'details' dus zou het
liever behouden zien, maar als het wordt gewijzigd dan uiteraard in allebei.

Voor de rest van dit bestand: je haalt hier een paar stukken witregel weg, maar
de opbouw was ook hier zodanig gemaakt dat deze identiek is aan de Engelse
versie t.b.v. duidelijkheid tijdens vertaling. Ik zou dat dus liever zo laten.


Index: nl/browser/chrome/browser/preferences/sanitize.dtd
===================================================================
ok. Overigens hou ik access keys liever hoofdlettergevoelig.


Index: nl/browser/chrome/browser/preferences/tabs.dtd
===================================================================

-<!ENTITY forceNewWindowLinks.label      "Koppelingen die openen in nieuwe
vensters forceren om te openen in:">
+<!ENTITY forceNewWindowLinks.label      "Koppelingen die openen in nieuwe
vensters, forceren om te openen in:">

De komma lijkt me harder nodig als er "Koppelingen die in nieuwe vensters openen
forceren om te openen in:" had gestaan maar hier niet zozeer. 2 werkwoorden
achter elkaar in dat geval, hier niet en daarom ook niet zo'n kans op verwarring.


Index: nl/toolkit/chrome/mozapps/extensions/extensions.dtd
===================================================================
ok, maar controleer wel of dit werkt i.v.m. een al gebruikte U. Dubbele beter
vermijden, ook als het wel werkt.


    
    

    
  
Comment on attachment 191838 [details] [diff] [review]
vertaling van de voorbeeld-css-bestanden

toegepast

        Attachment #191838 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Recente wijzigingen (obsolete)
        — 
          — Splinter Review
      

    


  
Correcties n.a.v. wijzigingen tussen 26/7 en vandaag. Ook andere zaken zoals
een aantal access keys, consistenties met TB, Engelstalige bestandsopmaak en de
wijzigingen van Paul.

    
    

    
  

      
      
      
      

        Attached file
          
        Feedview.properties (obsolete)
        — 
      

    


  
Maar apart omdat ie anders waarschijnlijk een hunk veroorzaakt (Linefeeds..)

    
    

    
  
wegens het branchen van de tree mogen er geen wijzigingen aangebracht worden. Op
het moment dat de tree weer open is zal ik de patches toepassen

Daarna zal ik deze bug sluiten en een nieuwe openen voor de branch.
cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/l10n checkout -r
MOZILLA_1_8_BRANCH l10n/nl

http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8-l10n-nl

http://bonsai-l10n.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=MOZILLA_1_8_BRANCH&branchtype=match&dir=l10n%2Fnl%2F&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=day&mindate=&maxdate=&cvsroot=%2Fl10n

    
    

    
  
(In reply to comment #100)
> Created an attachment (id=192620) [edit]
> Recente wijzigingen
> 
> Correcties n.a.v. wijzigingen tussen 26/7 en vandaag. Ook andere zaken zoals
> een aantal access keys, consistenties met TB, Engelstalige bestandsopmaak en de
> wijzigingen van Paul.

Onnodige witlijn geïntroduceerd (denk ik) in connection.dtd

-<!ENTITY  font.langGroup.canadian                 "Unified Canadian Syllabary">
+<!ENTITY  font.langGroup.canadian                 "Verenigd Canadees
syllabeschrift">
Moet dit niet 'Geünificeerd' zijn?  Verenigd lijkt me in deze context wat raar.
 Overigens is er wel wat voor te zeggen dit onvertaald te laten, daar het toch
een specifiek Engelse term is.

En ik snap niet echt waarom je steeds maar de volgorde van werkwoordgroepen moet
veranderen (veranderen moet); maar als het je blij maakt, mij niet gelaten hoor.

+<!ENTITY  sanitize.intro              "De functie Privé-gegevens opruimen kan
worden gebruikt om uw privé-gegevens te wissen door middel van een
sneltoetskoppeling of wanneer &brandShortName; afsluit.">
is zeker al een verbetering, maar ik zou 'u' er op het einde in laten (wanneer u
FF afsluit), en het begin is wat geconstrueerd; wat dacht je van 'De functie om
privé-gegevens op te ruimen kan...' of radicaler: 'Uw privé-gegevens kunnen
gewist worden door middel ...' dan wel 'U kunt uw privé-gegevens wissen door
middel...', of helemaal mooi: 'FF biedt de mogelijkheid uw privé-gegevens op te
ruimen...' (vooral die hoofdletter stoort me)

<!ENTITY forceNewWindowLinks.label      "Koppelingen die openen in nieuwe
vensters, forceren om te openen in:"> 
Deze extra komma vind ik echt onnodig, om niet te zeggen storend.

+ForcedBackup1=U kunt het beste een met een wachtwoord beschermde reservekopie
maken van uw nieuwe veiligheidscertificaat en de bijbehorende priv\u00E9-sleutel.
Moet zijn: '... uw nieuw veiligheidscertificaat ...'

+NSSInitProblem=Kan de beveiligingscomponent van de browser niet initialiseren.
De meest waarschijnlijke oorzaak is problemen met bestanden in de profielmap van
uw browser. Controleer of deze map geen lees/schrijf-beperkingen heeft en uw
harde schijf niet vol of bijna vol is. Het wordt aangeraden om de browser af te
sluiten en het probleem op te lossen. Als u doorgaat met deze sessie, is het
mogelijk dat u onjuist navigatiegedrag ziet tijdens toegang tot de
beveiligingsmogelijkheden.
Dat moet natuurlijk 'lees-/schrijfbeperkingen' zijn.

Amai, hele boterham.

Euhm, kan iemand mij even een beetje uitleggen wat die mededeling van Tim Maks
inhoudt?  Moet ik nu van een andere plaats mijn cvs-bestanden halen?

    
    

    
  
(In reply to comment #103)
> Euhm, kan iemand mij even een beetje uitleggen wat die mededeling van Tim Maks
> inhoudt?  Moet ik nu van een andere plaats mijn cvs-bestanden halen?
Ja, voor het voorbereiden van versie 1.5 is er nu een aftakking gemaakt waarin
de laatste stappen naar versie 1.5 gezet zullen worden. Nu kan ondertussen op de
trunk nieuwe code toegevoegd worden die voor een volgende versie van Firefox
(2.0) gebruikt kan worden. Voor de vertaling is hetzelfde gedaan en daarom moet
je nu eigenlijk de vertaling opnieuw downloaden om ook recente wijzigingen in
jouw lokale code te zien. 
Als je Tortoise gebruikt kan dat door in het tweede tabblad (Revisie) Kies tag
of branch aan te klikken en als tagnaam MOZILLA_1_8_BRANCH. 

Patches die gemaakt zijn werken nog gewoon, maar alleen voor nieuwe patches is
het handig om dit te gebruiken.

Tim Maks: Is het trouwens de bedoeling dat na de release van 1.5 alle
veranderingen terug naar de trunk gaan, of wil je gewoon de trunk gelijk houden
met de branch?

    
    

    
  
(In reply to comment #103)
> -<!ENTITY  font.langGroup.canadian                 "Unified Canadian Syllabary">
> +<!ENTITY  font.langGroup.canadian                 "Verenigd Canadees
> syllabeschrift">
> Moet dit niet 'Geünificeerd' zijn?  Verenigd lijkt me in deze context wat raar.
>  Overigens is er wel wat voor te zeggen dit onvertaald te laten, daar het toch
> een specifiek Engelse term is.

Het lijkt me niet dat dit onvertaald moet blijven. Volgens Wikipedia is dit:
"Canadees Aboriginal schrift". Ik kon dat terugvinden op:
http://nl.wikipedia.org/wiki/Abugida .

Dit is de vertaling zoals die in Gnome zit:
http://l10n-status.gnome.org/gnome-2.10/PO/gucharmap.gnome-2-10.nl.po

Om het zeker te weten zal je een taalexpert in inheemse talen ofzo om
uitsluitsel moeten vragen. Overigens vind ik de huidige vertaling ook helemaal
niet verkeerd.


> En ik snap niet echt waarom je steeds maar de volgorde van werkwoordgroepen
> moet veranderen (veranderen moet); maar als het je blij maakt, mij niet gelaten
> hoor.

Hmja, als het om triviale niet noodzakelijke veranderingen gaat kan je die als
je het mij vraagt beter niet maken dan je persoonlijke voorkeursschrijfstijl
overal toepassen (waar anderen dat later dan vervolgens weer ik hun stijl gaan
veranderen, etc).


> +ForcedBackup1=U kunt het beste een met een wachtwoord beschermde reservekopie
> maken van uw nieuwe veiligheidscertificaat en de bijbehorende priv\u00E9-sleutel.
> Moet zijn: '... uw nieuw veiligheidscertificaat ...'

Eh?? Wrom? Uw nieuw veiligheidscertificaat klinkt als ik turk zijn.


~Grauw

    
    

    
  
(In reply to comment #104)
>
> Tim Maks: Is het trouwens de bedoeling dat na de release van 1.5 alle
> veranderingen terug naar de trunk gaan, of wil je gewoon de trunk gelijk houden
> met de branch?

Op dit moment is de trunc in sync met de branch, laten we proberen dat zo te
houden. Maar op een zeker moment zal de trunk zodanig gaan afwijken van de
branch dat dat niet meer makkelijk kan.

    
    

    
  
(In reply to comment #103)
> 
> Onnodige witlijn geïntroduceerd (denk ik) in connection.dtd

Hoewel hij inderdaad niet nodig is zat de regel er al in en heb ik dat zo
gelaten, enkel omdat de Engelse versie hem ook (nog) heeft.

> -<!ENTITY  font.langGroup.canadian                 "Unified Canadian Syllabary">
> +<!ENTITY  font.langGroup.canadian                 "Verenigd Canadees
> syllabeschrift">
> Moet dit niet 'Geünificeerd' zijn?  Verenigd lijkt me in deze context wat raar.

Daar zit wat in; ik had ook mijn bedenkingen maar zag het ergens anders zo staan
en dacht ten onrechte dat de term al vaker ook zo was vertaald in FF/TB.
'Geünificeerd' is dan wel een niet-veelvoorkomende term, maar wel correcter.
'Geüniformeerd' kan ook nog volgens VD maar lijkt me niet zozeer beter, en
'eendrachtig' niet zo op zijn plaats. Niet vertalen is ook een optie, maar
waarom niet als dit ook met soortgelijke en andere doorgaans in het Engels
gehanteerde termen is gebeurd?

> En ik snap niet echt waarom je steeds maar de volgorde van werkwoordgroepen moet
> veranderen (veranderen moet); maar als het je blij maakt, mij niet gelaten hoor.

Dat komt dan waarschijnlijk doordat je Belg bent :-) (no offense). Ik
veronderstel dat je vast wel eens van 'rode en groene volgorde' hebt gehoord en
zoniet, dan raad ik aan om daar even naar te zoeken. En ja, goed om te zien dat
je er geen probleem mee hebt. :)

> +<!ENTITY  sanitize.intro              "De functie Privé-gegevens opruimen kan
> worden gebruikt om uw privé-gegevens te wissen door middel van een
> sneltoetskoppeling of wanneer &brandShortName; afsluit.">
> is zeker al een verbetering, maar ik zou 'u' er op het einde in laten (wanneer u
> FF afsluit), en het begin is wat geconstrueerd; wat dacht je van 1) 'De functie om
> privé-gegevens op te ruimen kan...' of radicaler: 2) 'Uw privé-gegevens kunnen
> gewist worden door middel ...' dan wel 3) 'U kunt uw privé-gegevens wissen door
> middel...', of helemaal mooi: 4) 'FF biedt de mogelijkheid uw privé-gegevens op te
> ruimen...' (vooral die hoofdletter stoort me)

'U' is er in het Engels ook uitgehaald. Dit was me wel opgevallen en ik vond het
wat onwennig in het begin maar het went snel, ook omdat FF op meer plaatsen in
de teksten 'zelf' afsluit.
Je alternatieven: 1) lijkt me niet zo'n goed idee vanwege 'functie om', maar ook
omdat de volledige functienaam moet worden behouden. Dat laatste geldt ook voor
2), 3) en 4) en veroorzaakt ook de hoofdletter, wat niet ongewoon is voor het
benoemen van functies. 4) is ook wat formeel en lijkt me meer geschikt voor een
helptekst.
Het enige wat misschien vreemd aandoet en je denk ik met geconstrueerd bedoelt
is 'kan worden gebruikt'; beter lijkt 'dient', maar toch is het eerste beter
omdat het op de 2 manieren slaat. Ik zie dus vooralsnog geen reden tot wijzigen,
maar wellicht dat deze tekst nog gaat veranderen aangezien hij een paar dagen
oud is en men nog met de functie bezig is.

> <!ENTITY forceNewWindowLinks.label      "Koppelingen die openen in nieuwe
> vensters, forceren om te openen in:"> 
> Deze extra komma vind ik echt onnodig, om niet te zeggen storend.

Dat vond ik dus ook, maar daarna dacht ik er goed aan te doen hem toch maar te
plaatsen omdat er sprake zou zijn van een bijvoeglijke bijzin. Het gaat hier
echter om een voorwerp, waardoor een komma niet op zijn plaats is. (Zie
http://taalunieversum.org/taal/advies/vraag/461/).

> +ForcedBackup1=U kunt het beste een met een wachtwoord beschermde reservekopie
> maken van uw nieuwe veiligheidscertificaat en de bijbehorende priv\u00E9-sleutel.
> Moet zijn: '... uw nieuw veiligheidscertificaat ...'

Sorry, maar na een bezittelijk voornaamwoord volgt naar mijn weten de verbogen
vorm van het bijvoeglijk naamwoord.

> uw browser. Controleer of deze map geen lees/schrijf-beperkingen heeft en uw
> Dat moet natuurlijk 'lees-/schrijfbeperkingen' zijn.

Ook daarin moet ik je ongelijk geven. (Zie
http://taalunieversum.org/taal/advies/vraag/517).


    
    

    
  
(In reply to comment #107)
> > uw browser. Controleer of deze map geen lees/schrijf-beperkingen heeft en uw
> > Dat moet natuurlijk 'lees-/schrijfbeperkingen' zijn.
> 
> Ook daarin moet ik je ongelijk geven. (Zie
> http://taalunieversum.org/taal/advies/vraag/517).

Uh, die vraag heeft niks met dit te maken. De vraag gaat over het al dan niet
gebruiken van de /. En in dat antwoord staat duidelijk "Gebruik hem alleen in
(...) het geval van keuzemogelijkheden zoals: man/vrouw, en/of". Hij is hier dus
wel degelijk van toepassing.

Het belangrijke punt hier is echter: ‘schrijfbeperkingen’ is een samenstelling,
en in het Nederlands wordt de - als afkorting gebruikt bij herhalingen in
samenstellingen. Dus lees-/schrijfbeperkingen is wel degelijk correct (denk ook
aan lees- en schrijfbeperkingen, waar de - hetzelfde wordt gebruikt maar de / is
vervangen).


~Grauw

    
    

    
  
Het gaat dus om de afwezigheid van leesbeperkingen en schrijfbeperkingen. Dat
zijn twee soorten beperkingen. Als je lees/schrijf-beperkingen schrijft, dan zou
het om één beperking gaan, van het type ‘lees/schrijf’.

~Grauw

    
    

    
  
(In reply to comment #107)
> (In reply to comment #103)

> 'eendrachtig' niet zo op zijn plaats. Niet vertalen is ook een optie, maar
> waarom niet als dit ook met soortgelijke en andere doorgaans in het Engels
> gehanteerde termen is gebeurd?

Er moet hier toch wel ergens een talenstudent rondlopen die dit eens kan
navragen? (Ik jammer genoeg niet, want net naar Duitsland verhuisd)
 
> > En ik snap niet echt waarom je steeds maar de volgorde van werkwoordgroepen moet
> > veranderen (veranderen moet); maar als het je blij maakt, mij niet gelaten hoor.
> 
> Dat komt dan waarschijnlijk doordat je Belg bent :-) (no offense). Ik
> veronderstel dat je vast wel eens van 'rode en groene volgorde' hebt gehoord en
> zoniet, dan raad ik aan om daar even naar te zoeken. En ja, goed om te zien dat
> je er geen probleem mee hebt. :)

Ik weet perfect waar je het over hebt, en ik wou alleen maar suggereren wat
Grauw hierboven zegt: dat je zulke veranderingen ook even goed kunt achterwege
laten.
 
> > +<!ENTITY  sanitize.intro              "De functie Privé-gegevens opruimen kan
> > worden gebruikt om uw privé-gegevens te wissen door middel van een
> > sneltoetskoppeling of wanneer &brandShortName; afsluit.">
> > is zeker al een verbetering, maar ik zou 'u' er op het einde in laten (wanneer u
> > FF afsluit), en het begin is wat geconstrueerd; wat dacht je van 1) 'De
functie om
> > privé-gegevens op te ruimen kan...' of radicaler: 2) 'Uw privé-gegevens kunnen
> > gewist worden door middel ...' dan wel 3) 'U kunt uw privé-gegevens wissen door
> > middel...', of helemaal mooi: 4) 'FF biedt de mogelijkheid uw privé-gegevens
op te
> > ruimen...' (vooral die hoofdletter stoort me)
> 
> 'U' is er in het Engels ook uitgehaald. Dit was me wel opgevallen en ik vond het
> wat onwennig in het begin maar het went snel, ook omdat FF op meer plaatsen in
> de teksten 'zelf' afsluit.
> Je alternatieven: 1) lijkt me niet zo'n goed idee vanwege 'functie om', maar ook
> omdat de volledige functienaam moet worden behouden. Dat laatste geldt ook voor
> 2), 3) en 4) en veroorzaakt ook de hoofdletter, wat niet ongewoon is voor het
> benoemen van functies. 4) is ook wat formeel en lijkt me meer geschikt voor een
> helptekst.
> Het enige wat misschien vreemd aandoet en je denk ik met geconstrueerd bedoelt
> is 'kan worden gebruikt'; beter lijkt 'dient', maar toch is het eerste beter
> omdat het op de 2 manieren slaat. Ik zie dus vooralsnog geen reden tot wijzigen,
> maar wellicht dat deze tekst nog gaat veranderen aangezien hij een paar dagen
> oud is en men nog met de functie bezig is.

Nee, wat me zo vreemd aandoet is "De functie Privé-gegevens opruimen kan
..." Ik zou dan bv. de functienaam tussen aanhalingstekens zeten of zo, vooral
omdat het niet duidelijk is waar de naam eindigt (probleem met namen die uit
meerdere woorden bestaan).  Daarom zou ik voor een beschrijving opteren.
 
> > <!ENTITY forceNewWindowLinks.label      "Koppelingen die openen in nieuwe
> > vensters, forceren om te openen in:"> 
> > Deze extra komma vind ik echt onnodig, om niet te zeggen storend.
> 
> Dat vond ik dus ook, maar daarna dacht ik er goed aan te doen hem toch maar te
> plaatsen omdat er sprake zou zijn van een bijvoeglijke bijzin. Het gaat hier
> echter om een voorwerp, waardoor een komma niet op zijn plaats is. (Zie
> http://taalunieversum.org/taal/advies/vraag/461/).

Je hebt gelijk, puntje (8).
 
> > +ForcedBackup1=U kunt het beste een met een wachtwoord beschermde reservekopie
> > maken van uw nieuwe veiligheidscertificaat en de bijbehorende
priv\u00E9-sleutel.
> > Moet zijn: '... uw nieuw veiligheidscertificaat ...'
> 
> Sorry, maar na een bezittelijk voornaamwoord volgt naar mijn weten de verbogen
> vorm van het bijvoeglijk naamwoord.

Hm, daar schijnt de ANS je gelijk te geven, mijn taalgevoel echter niet :-(

> > uw browser. Controleer of deze map geen lees/schrijf-beperkingen heeft en uw
> > Dat moet natuurlijk 'lees-/schrijfbeperkingen' zijn.
> 
> Ook daarin moet ik je ongelijk geven. (Zie
> http://taalunieversum.org/taal/advies/vraag/517).

Zie de opmerkingen van Grauw.  Hier heb ik toch echt wel gelijk.

H.

    
    

    
  
(In reply to comment #110)
> Ik weet perfect waar je het over hebt, en ik wou alleen maar suggereren wat
> Grauw hierboven zegt: dat je zulke veranderingen ook even goed kunt achterwege
> laten.

Noot: ik heb de daadwerkelijke patch niet doorgelezen, dus ik weet niet precies
om wat voor veranderingen het gaat. Gaat het om gevallen zoals "even goed kunt
achterwege laten" dan ben ik ook 100% voorstander om dat in "even goed
achterwege kunt laten" te veranderen, omdat die woordvolgorde gewoon
on-Nederlands is (als ik docent was zou ik het fout rekenen ;p), en je dan
klachten gaat krijgen dat de vertaling Vlaams aan doet.


~Grauw

    
    

    
  


  
de line-endings van userChrome-example.css waren niet ok (denk ik), verder
enkele commentaren bij zoekmachines en andere kleinigheidjes

    
    

    
  
Comment on attachment 191883 [details] [diff] [review]
Kleine foutjes (voornamelijk accesskeys)

patch toegepast in de trunk en branch behalve:
- /l10n/l10n/nl/browser/chrome/browser/preferences/privacy.dtd
ivm comment #97

        Attachment #191883 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 192620 [details] [diff] [review]
Recente wijzigingen

Zou je deze patch overnieuw kunnen maken, met de opmerkingen/ discussie daarin
verwerkt en gemaakt op de huidige trunk/branch. Sorry.

        Attachment #192620 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 192622 [details]
Feedview.properties

bestand wordt niet meer gebruikt

        Attachment #192622 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 192916 [details] [diff] [review]
enkele kleinigheden + line-endings

toegepast op de trunk en branch

        Attachment #192916 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #111)
> (In reply to comment #110)
> > Ik weet perfect waar je het over hebt, en ik wou alleen maar suggereren wat
> > Grauw hierboven zegt: dat je zulke veranderingen ook even goed kunt achterwege
> > laten.
> 
> Noot: ik heb de daadwerkelijke patch niet doorgelezen, dus ik weet niet precies
> om wat voor veranderingen het gaat. Gaat het om gevallen zoals "even goed kunt
> achterwege laten" dan ben ik ook 100% voorstander om dat in "even goed
> achterwege kunt laten" te veranderen, omdat die woordvolgorde gewoon
> on-Nederlands is (als ik docent was zou ik het fout rekenen ;p), en je dan
> klachten gaat krijgen dat de vertaling Vlaams aan doet.

Het gaat inderdaad om zulke gevallen, maar dan meestal met het voltooid
deelwoord.  En als je zo doorgaat, dan ga ik echt nog eens een nl-BE versie
beginnen.  Met zo bedoel ik: spreken alsof Vlaams geen Nederlands is.  En het
zou me verbazen als je daar klachten over krijgt.  De oorspronkelijke
vertalingen zijn tenslotte ook door Nederlanders gemaakt, of heb ik het mis?

    
    

    
  
(In reply to comment #108)
> 
> Uh, die vraag heeft niks met dit te maken. De vraag gaat over het al dan niet
> gebruiken van de /. En in dat antwoord staat duidelijk "Gebruik hem alleen in
> (...) het geval van keuzemogelijkheden zoals: man/vrouw, en/of". Hij is hier dus
> wel degelijk van toepassing.
>

Yep, en gelukkig maar. In mijn 'posthaast' maandag had ik dit laatste geval te
snel geclassificeerd als een keuzemogelijkheid, terwijl het een duidelijk
gevalletje kosten-/batenanalyse is. Vandaar ook "helaas gelijk moeten geven"
(maar dan zonder 'helaas') want ik vond het er al niet uitzien en de genoemde
verwarring lag voor de hand.

> samenstellingen. Dus lees-/schrijfbeperkingen is wel degelijk correct (denk ook
> aan lees- en schrijfbeperkingen, waar de - hetzelfde wordt gebruikt maar de / is
> vervangen).

Idd, het is dan enkel verleidelijk om de - en / als dubbelop te zien. Btw, ik
heb de term niet geïntroduceerd in de patch. :)

    
    

    
  
(In reply to comment #110)
> 
> Ik weet perfect waar je het over hebt, en ik wou alleen maar suggereren wat
> Grauw hierboven zegt: dat je zulke veranderingen ook even goed kunt achterwege
> laten.

Natuurlijk weet je dat, ik verwachtte niet anders. :) Maar 'net zo goed
achterwege laten' snijdt geen hout want ik wijzig ze niet voor niets. Voordat er
hierover nog verder wordt gespeculeerd: alhoewel de rode/groene volgorde
hoofdzakelijk betrekking heeft op de hulpwerkwoorden worden, zijn en hebben ging
het mij nu enkel om het gelijktrekken van 'worden' en in mindere mate om die van
'is'. Op dit moment zijn er een aantal voorkomens in de teksten die behoorlijk
herkenbaar zijn en enigszins uit de toon vallen, dus enkele daarvan had ik
meegenomen omdat er meer wijzigingen in die bestanden waren; andere zouden nog
volgen als daar geen bezwaar tegen bestaat. Ook had ik jou (Hendrik) willen
vragen om de helpteksten daarin ook aan te passen omdat juist die hierin erg
opvallen en als je er hier geen zin in hebt, of je er bezwaar tegen hebt als dat
door iemand anders wordt gewijzigd. Bij deze.
N.B. het is dus geen kwestie van mijn persoonlijke voorkeursschrijfstijl of hele
werkwoordgroepen als 'evengoed kunt achterwege laten' veranderen, alhoewel de
laatste hier ook wel onder vallen maar als ik het goed heb gezien niet
voorkomen. Het is echter wel iets essentieels wat vooral in veel open-source
vertalingen wordt vergeten.

> Nee, wat me zo vreemd aandoet is "De functie Privé-gegevens opruimen kan
> ..." Ik zou dan bv. de functienaam tussen aanhalingstekens zeten of zo, vooral
> omdat het niet duidelijk is waar de naam eindigt (probleem met namen die uit
> meerdere woorden bestaan).  Daarom zou ik voor een beschrijving opteren.

Aha, dat is inderdaad storend en aanhalingstekens zouden niet misstaan, maar ik
heb begrepen dat dit met opzet nergens gebeurt. Voor enkele woorden valt het nog
niet zo op maar bij twee of drie inderdaad wel. Misschien is het een idee om af
te spreken die wel te voorzien van aanhalingstekens? Bovendien makkelijker (en
mooier) dan herschrijven van hele regels. Echt bezwaarlijk vind ik het echter
niet en ook MS laat ze als ik me niet vergis achterwege, dus er is vermoedelijk
wel sprake van een soort gewenning bij de lezer, althans bij MS-gebruikers.


    
    

    
  
(In reply to comment #114)
> (From update of attachment 192620 [details] [diff] [review] [edit])
> Zou je deze patch overnieuw kunnen maken, met de opmerkingen/ discussie daarin
> verwerkt en gemaakt op de huidige trunk/branch. Sorry.

Hmm, ik had het fijner gevonden als je deze had uitgevoerd; de wijzigingen van
Paul zaten er ook in en herstellen van enkele zaken achteraf en vooral na
eventuele nieuwe wijzigingen was een stuk makkelijker geweest.. :-]

Maar begrijp ik goed dat er nu zowel met een trunk als een branch wordt gewerkt
en wijzigingen nu in tweevoud (moeten) plaatsvinden?

    
    

    
  
(In reply to comment #120)
> (In reply to comment #114)
> > (From update of attachment 192620 [details] [diff] [review] [edit] [edit])
> > Zou je deze patch overnieuw kunnen maken, met de opmerkingen/ discussie daarin
> > verwerkt en gemaakt op de huidige trunk/branch. Sorry.
> 
> Hmm, ik had het fijner gevonden als je deze had uitgevoerd; de wijzigingen van
> Paul zaten er ook in en herstellen van enkele zaken achteraf en vooral na
> eventuele nieuwe wijzigingen was een stuk makkelijker geweest.. :-]
> 
> Maar begrijp ik goed dat er nu zowel met een trunk als een branch wordt gewerkt
> en wijzigingen nu in tweevoud (moeten) plaatsvinden?

En hierop aansluitend: Moet ik nu twee cvs-projecten aanmaken, en in allebei
werken, of bewerk ik enkel de branch dan wel de trunk, en wat gebeurt er met
wijzigingen in de branch als die afgesloten wordt enz. (dat valt wsch ook in een
cvs-handleiding te lezen, maar 't is zoveel makkelijker als iemand het snel even
uitlegt...)(evt. per e-mail) 

    
    

    
  
(In reply to comment #119)
> (In reply to comment #110)
> > 
> > Ik weet perfect waar je het over hebt, en ik wou alleen maar suggereren wat
> > Grauw hierboven zegt: dat je zulke veranderingen ook even goed kunt achterwege
> > laten.
> 
> Natuurlijk weet je dat, ik verwachtte niet anders. :) Maar 'net zo goed
> achterwege laten' snijdt geen hout want ik wijzig ze niet voor niets. Voordat er
> hierover nog verder wordt gespeculeerd: alhoewel de rode/groene volgorde
> hoofdzakelijk betrekking heeft op de hulpwerkwoorden worden, zijn en hebben ging
> het mij nu enkel om het gelijktrekken van 'worden' en in mindere mate om die van
> 'is'. Op dit moment zijn er een aantal voorkomens in de teksten die behoorlijk
> herkenbaar zijn en enigszins uit de toon vallen, dus enkele daarvan had ik
> meegenomen omdat er meer wijzigingen in die bestanden waren; andere zouden nog
> volgen als daar geen bezwaar tegen bestaat. Ook had ik jou (Hendrik) willen
> vragen om de helpteksten daarin ook aan te passen omdat juist die hierin erg
> opvallen en als je er hier geen zin in hebt, of je er bezwaar tegen hebt als dat
> door iemand anders wordt gewijzigd. Bij deze.
> N.B. het is dus geen kwestie van mijn persoonlijke voorkeursschrijfstijl of hele
> werkwoordgroepen als 'evengoed kunt achterwege laten' veranderen, alhoewel de
> laatste hier ook wel onder vallen maar als ik het goed heb gezien niet
> voorkomen. Het is echter wel iets essentieels wat vooral in veel open-source
> vertalingen wordt vergeten.

Hm, het moet blijkbaar daar in het noorden gevoelig liggen, want ik heb
überhaupt geen problemen met de rode dan wel groene volgorde.  Maar als jij dat
blijkbaar essentieel vind, dan wil ik me daar bij neerleggen.
Ik zal dan ook de hulpteksten aanpassen, maar dat zal nog een paar weken moeten
wachten, want die bestanden staan op een andere computer die momenteel 700km van
hier is.

> > Nee, wat me zo vreemd aandoet is "De functie Privé-gegevens opruimen kan
> > ..." Ik zou dan bv. de functienaam tussen aanhalingstekens zeten of zo, vooral
> > omdat het niet duidelijk is waar de naam eindigt (probleem met namen die uit
> > meerdere woorden bestaan).  Daarom zou ik voor een beschrijving opteren.
> 
> Aha, dat is inderdaad storend en aanhalingstekens zouden niet misstaan, maar ik
> heb begrepen dat dit met opzet nergens gebeurt. Voor enkele woorden valt het nog
> niet zo op maar bij twee of drie inderdaad wel. Misschien is het een idee om af
> te spreken die wel te voorzien van aanhalingstekens? Bovendien makkelijker (en
> mooier) dan herschrijven van hele regels. Echt bezwaarlijk vind ik het echter
> niet en ook MS laat ze als ik me niet vergis achterwege, dus er is vermoedelijk
> wel sprake van een soort gewenning bij de lezer, althans bij MS-gebruikers.

Ik had ooit al eens aanhalingstekens voorgesteld, Martijn Ras vond dat toen wel
goed, maar ik weet niet of daar ooit iets van gekomen is (misschien in de
Mozilla Suite?).  Achteraf gekeken vind ik het toch niet zo'n mooie oplossing.
Ik zou het geval per geval bekijken en herschrijven dan wel aanhalingstekens
zetten waar verwarring nodig.  En als iedereen zich bewust is van het probleem,
dan treden er als het goed is geen nieuwe gevallen meer op...
Als echter voor aanhalingstekens gekozen wordt, dan zou dat liefst consequent
doorgetrokken moeten worden, en dan ook voor de functienamen die maar uit één
woord bestaan. Daarom vind ik het niet zo goed, ook omdat het dan nogal ver
afwijkt van het origineel.

    
    

    
  
(In reply to comment #120)
> Hmm, ik had het fijner gevonden als je deze had uitgevoerd; de wijzigingen van
> Paul zaten er ook in en herstellen van enkele zaken achteraf en vooral na
> eventuele nieuwe wijzigingen was een stuk makkelijker geweest.. :-]
> 
Je had dat dan even wat duidelijker moeten aangeven dat je patch een vervanging
van die van Paul was, maar zelf dan vind ik het niet handig en loop je het
risico dat een patch niet toegepast wordt omdat het er on overzichtelijk wordt

> Maar begrijp ik goed dat er nu zowel met een trunk als een branch wordt gewerkt
> en wijzigingen nu in tweevoud (moeten) plaatsvinden?

We gaan nu werken vanuit de branch en je hoeft dus maar een patch te maken. Alle
patches zal ik ook nog toepassen op de trunk zolang die nog gelijk loopt met de
branch.

op het einde van de rit worden alle verbeteringen uit de branch weer
toegegevoegd aan de trunk (zover dat nog niet gebeurt was)

    
    

    
  
De verbeteringen voor Fx en Tb 1.5 kunnen worden toegevoegd aan bug 305315
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Recente wijzigingen (2) (obsolete)
        — 
          — Splinter Review
      

    


  
Mijn laatste patch uit bug 297896 opnieuw, met wat kleinigheden toegevoegd.

N.B. ook nu heb ik ter voorkoming van problemen alle wijzigingen van Paul uit
att 193339 meegenomen vanwege pippki.properties (met wat extra's in
importMsgs.properties), dus gelieve die niet toe te passen.

Hetzelfde geldt voor een gedeelte van att 193360 van Hendrik. Aangezien de
laatste drie bestanden daarin (HtmlForm.properties, css.properties en
printing.properties) ook in mijn patch worden gewijzigd heb ik zijn
wijzigingen, op 'method+e' na (is een kreet als 'method\=POST' net als
'enctype\=..' niet iets wat het beste Engels kan blijven?), erin meegenomen.
Alles ervoor kan dus wel worden toegepast. Wel verwacht ik daarin problemen in
installer.inc a.g.v. de 'ï' (UTF..) maar ik wou er later ook nog doorheen
fietsen i.v.m. resterende (en nieuwe ;-)) groene volgorde, dus dit hoeft nog
geen probleem te zijn.

    
    

    
  
Comment on attachment 193374 [details] [diff] [review]
Recente wijzigingen (2)

Foutje..

        Attachment #193374 -
        Attachment filename: ffrecent2-2.patch

        Attachment #193374 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #117)
> Het gaat inderdaad om zulke gevallen, maar dan meestal met het voltooid
> deelwoord.  En als je zo doorgaat, dan ga ik echt nog eens een nl-BE versie
> beginnen.  Met zo bedoel ik: spreken alsof Vlaams geen Nederlands is.  En het
> zou me verbazen als je daar klachten over krijgt.  De oorspronkelijke
> vertalingen zijn tenslotte ook door Nederlanders gemaakt, of heb ik het mis?

Om even een voorbeeld te geven, er zijn een viertal uitgevers van Japanse
animatie in Nederland actief, en daarvan zijn de drie belangrijkste alledrie in
België gevestigd, in verband met de Franse markt, affijn dat is verder niet
belangrijk. Waar het om gaat is dat, er zijn bij die bedrijven concrete klachten
geweest dat de vertalingen Vlaams aandeden bij hun Nederlandse klanten, en er
zijn hierop daadwerkelijk mensen afgeknapt. De betreffende bedrijven hebben
hierop hun vertalingen dus aangepast om ze meer te ‘Nederlands’ te maken.

Ik wil op geen manier Vlaams bekritiseren, ik vind het een prachtige uitspaak en
mooi woordgebruik. Maar de taal, alhoewel grotendeels Nederlands, *wordt* apart
aangeduid als Vlaams en dat niet zonder reden, maar omdat er daadwerkelijke
verschillen tussen zitten. Bepaalde Vlaamse uitdrukkingen doen nou eenmaal
vreemd of zelfs onjuist aan voor Nederlanders, en dit is inderdaad een nl-NL
vertaling en geen nl-BE.


~Grauw

    
    

    
  
Overigens vind ik het verschil tussen rode en groene volgorde zoals hier uitgelegd:

http://www.onzetaal.nl/advies/groenrood.html

Niet dermate groot dat dat een wijziging rechtvaardigd. Beide vormen klinken als
normaal Nederlands. Maar dit zal per zin verschillen, en sommige dingen ("even
goed kunt achterwege laten") zullen in het Nederlands gewoon niet gezegd worden.


~Grauw

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: