Closed Bug 305315 Opened 19 years ago Closed 19 years ago

Dutch (nl) translation of Thunderbird and Firefox 1.5 branch

Categories

(Mozilla Localizations :: nl / Dutch, defect)

Product:
Mozilla Localizations
Component:
nl / Dutch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: mad_maks, Unassigned)

References

Details

Attachments

(3 files, 80 obsolete files)

screenshot van themabeheerder
30.45 KB, image/jpeg
Details
Ook een screenshot van themabeheerder
21.90 KB, image/jpeg
Details
Thema’s bij mij, zonder cleartype
9.03 KB, image/png
Details 
cvs -d :pserver:anonymous@cvs-mirror.mozilla.org:/l10n checkout -r
MOZILLA_1_8_BRANCH l10n/nl
Ik heb de readme voor OS/2 vertaald.

Verder installer.inc leesbaarder gemaakt, en kleinere dingen onder /dom
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 193375 [details] [diff] [review]
Recente wijzigingen (2)

patch toegepast in branch en trunk.
Attachment #193375 - Attachment is obsolete: true
Comment on attachment 193360 [details] [diff] [review]
readme OS/2 vertaald, verbeteringen aan dom en installer

patch toegepast in de branch en trunk
Attachment #193360 - Attachment is obsolete: true
Comment on attachment 193339 [details] [diff] [review]
Een paar kleine foutjes in Thunderbird (en sommige ook Firefox)

patch is toegepast via de pach van Tonnes
Attachment #193339 - Attachment is obsolete: true
Paar keer licentiecommentaar toegevoegd, enkele `verbeteringen' (naar mijn
gevoel) en enkele nieuwe vertalingen.  Deze laatste doen wel nog zeer Engels
aan, dus graag suggesties ter verbetering.  

Verder vroeg ik me af of er een trucje is om bepaalde zinnen in hun context te
zien te krijgen, het is anders nogal moeilijk om te weten hoe je iets als 
SOAPFault = SOAP { %S } %S call resulted in fault: { %S } %S : %S.
vertaalt: moet er een streepje voor oproep, wat betekenen al die S'en enz.

Verder heb ik nog niet ontdekt hoe ik op deze Linuxmachine dat speciale accent
dat we hier gebruiken moet intypen.  \u2019 kan ook, maar is moeilijk te
onthouden, heeft iemand een tip (internationaal qwerty met deadkeys ingesteld,
maar rechter-Alt-toets lijkt niet te werken)
(In reply to comment #8)
xbl.properties:

+UnexpectedElement=Onverwacht <%1$S>-element
Weet je zeker dat het hier inderdaad om een samenstelling gaat? Daarom had ik
hem zo gelaten namelijk.

xmlparser.properties:

-5 = niet-afgesloten token
+5 = onafgesloten token
-20 = niet-afgesloten CDATA-sectie
+20 = onafgesloten CDATA-sectie
-XMLParsingError = XML-parsefout: %1$S\nLocatie: %2$S\nRegelnummer %3$d, kolom %4$d:
+XMLParsingError = XML-ontleedfout: %1$S\nLocatie: %2$S\nRegelnummer %3$d, kolom
%4$d:

Hoewel deze 3 strings allemaal eerder 'in de andere richting' zijn gewijzigd leg
ik me nu wel neer bij de eerste 2. 'XML-parsefout' is echter verkozen boven
'ontleedfout' (en parserfout) na (IRC-)overleg met Laurens. Overigens staat
zowel parser als parsen in Van Dale.

caps.properties:

Hier zou ik, net als overal trouwens,  kleine letters na een dubbele punt
gebruiken, tenzij sprake is van de geldende voorwaarden. Ook vereisen letters
als de ë Unicode-notatie, en EnableCapabilityDenied kan misschien beter iets met
'onthouden' worden. 'Private data' kan denk ik net als overal worden vertaald
met privé-gegevens, en 'je' computer -> uw / laten lopen -> uitvoeren? 'Van de
kern' en 'negeren' kunnen wellicht ook beter. Misschien
'kernveiligheidsinstellingen omzeilen'? Behouden van 'software' vind ik wel OK
en zie dat graag overal, maar daar heerst geloof ik een taboe op.. (?) Verder
wel OK.

(In reply to comment #9)
> (In reply to comment #8)
> xbl.properties:
> 
> +UnexpectedElement=Onverwacht <%1$S>-element
> Weet je zeker dat het hier inderdaad om een samenstelling gaat? Daarom had ik
> hem zo gelaten namelijk.

Niet zeker, maar het lijkt er wel op: de vishaakjes horen nl. niet bij de
ingevoegde string.  Dat wil dus zeggen dat er in het eindresultaat iets als 
Onverwacht <ul>-element of zo zal staan, en dat rechtvaardigt het streepje.  Of
heb ik het mis?  Bestaat er een manier om gegeven en zekere entity, deze aan het
werk te zien, of moet je daarvoor `geluk' hebben? (In dit geval eerder ongeluk
omdat het om een ontleedfout zal gaan)

> xmlparser.properties:
> 
> -5 = niet-afgesloten token
> +5 = onafgesloten token
> -20 = niet-afgesloten CDATA-sectie
> +20 = onafgesloten CDATA-sectie
> -XMLParsingError = XML-parsefout: %1$S\nLocatie: %2$S\nRegelnummer %3$d, kolom
%4$d:
> +XMLParsingError = XML-ontleedfout: %1$S\nLocatie: %2$S\nRegelnummer %3$d, kolom
> %4$d:
> 
> Hoewel deze 3 strings allemaal eerder 'in de andere richting' zijn gewijzigd leg
> ik me nu wel neer bij de eerste 2. 'XML-parsefout' is echter verkozen boven
> 'ontleedfout' (en parserfout) na (IRC-)overleg met Laurens. Overigens staat
> zowel parser als parsen in Van Dale.

Het moet niet van mij hoor, het zijn voorstellen die, wat mij betreft,
vlotter/natuurlijker klinken.  Ontleedfout heb ik veranderd naar andere
voorbeelden, o.a. in xslt.properties en in messenger.properties, en `ontleden'
in css.properties.  Vind het wel mooier en in de context even duidelijk als
parse (wat vziw alleen in taalkundige context wordt gebruikt?)

> caps.properties:

Hier kijk ik nog eens naar, bedankt voor de opmerkingen!
(In reply to comment #4)
> wijzigingen, op 'method+e' na (is een kreet als 'method\=POST' net als
> 'enctype\=..' niet iets wat het beste Engels kan blijven?), erin meegenomen.

In de lessen Java die ik het afgelopen half jaar gehad heb, en ik denk vrij
algemeen onder informatici, wordt gewoon methode gezegd en geschreven.

(In reply to comment #11)
> > wijzigingen, op 'method+e' na (is een kreet als 'method\=POST' net als
> > 'enctype\=..' niet iets wat het beste Engels kan blijven?), erin meegenomen.
> 
> In de lessen Java die ik het afgelopen half jaar gehad heb, en ik denk vrij
> algemeen onder informatici, wordt gewoon methode gezegd en geschreven.

Hendrik: daar gaat het niet om. De tekst betreft een ‘method’ attribuut op een
‘form’ tag met de waarde ‘POST’. Dat moet je intact houden. Om dezelfde reden
staat er in het Engels ook ‘enctype’ (wat geen bestaand Engels woord is) en geen
‘encoding type’. Verder is er natuurlijk niks mis met als methode vertalen.

Om dezelfde reden is ‘ontleedfout’ een onhandige vertaling, omdat de foutmelding
dan moeilijk terug te herleiden is naar de oorspronkelijke Engelse terminologie
in XML (waar geen ‘officiele’ Nederlandse vertalingen voor bestaan). De eerste
keer dat ik die melding zag moest ik echt even heel hard nadenken wat ermee
bedoeld werd, en dat is niet de bedoeling.

Zodoende.


~Grauw
Comment on attachment 193552 [details] [diff] [review]
vertalingen en verbeteringen van hele rist .properties

Zou je de opmerkingen van ~grauw willen verwerken in een nieuwe patch?
Attachment #193552 - Attachment is obsolete: true
- ontleed -> parse
- caps.properties bijgewerkt

Verder nog een aantal nieuwe wijzigingen in nl/dom, ik ben nu klaar met deze
hele map, vandaar samen.  Herschikkingen, synchronisaties en taaldingen.
Comment on attachment 193797 [details] [diff] [review]
opmerkingen toegepast en nog enkele bestanden bij

patch toegepast op de trunk en branch
Attachment #193797 - Attachment is obsolete: true
Attached patch Installer (obsolete) — — Splinter Review 
Beloofde wijzigingen aan installer.inc, een hoofdletter en een dubbele access
key.

P.S. Jammer dat att. 193797 zo snel is uitgevoerd. Reviewen is haast onmogelijk
en volgens mij mankeert hier nogal wat aan..
(In reply to comment #16)
> Created an attachment (id=193802) [edit]
> Installer
> 
> Beloofde wijzigingen aan installer.inc, een hoofdletter en een dubbele access
> key.

#define TYPE_CUSTOM_DESC U kunt individuele onderdelen kiezen om te worden
geïnstalleerd. Aanbevolen voor ervaren gebruikers.
Dit vind ik een beetje krom Nederlands.  worden geïnstalleerd -> installeren is
beter, maar nog beter: u kunt kiezen welke (individuele) onderdelen worden
geïnstalleerd (rode volgorde toch?), waar ik individuele zou weglaten wegens
overbodig.

#define DL_FILENAME Nu downloadend:
Dat vind ik echt niet mooi hoor.  Wie gebruikt er tegenwoordig nog onvoltooid
deelwoord...  Veel te letterlijke vertaling van now downloading.  Ik vind
Bestand: zoals het er stond best wel een goede oplossing.
#define INSTALL_STATUSCOMP Nu installerend: 
idem

#define MSG_STATUS_DL %s aan %.2f KB/sec (%u KB van %u KB gedownload)
#define MSG_STATUS_DL %s met %.2f KB/sec (%u KB van %u KB gedownload)
Deze had ik dus net ervoor in de omgekeerde richting veranderd.  Je fietst toch
aan 20km/u en niet met 20km/u?

#define MSG_USAGE ...
Met de meeste wijzigingen eens, behalve gaat -> gaan.  Het is het
installatieprogramma dat ervan uitgaaT dat, niet de andere modi die ervan
uitgaaN dat (redelijk tegen het einde)  Overigens twijfel ik of we niet NORMAL
modus moeten schrijven i.p.v. NORMALE (iets soortgelijks aan method i.p.v. methode)

#define MB_ATTENTION_STR Attentie
Wat is er mis met aandacht?????

En hoe komt het dat jouw ï's als ï verschijnen terwijl de mijne wel er gewoon
als ï uitzien?

> P.S. Jammer dat att. 193797 zo snel is uitgevoerd. Reviewen is haast onmogelijk
> en volgens mij mankeert hier nogal wat aan..

Ja, ik vond het ook al snel gaan.  Maar niemand houdt je tegen om net als
hierboven al mijn wijzigingen weer ongedaan te maken :-p
(In reply to comment #16)

> P.S. Jammer dat att. 193797 zo snel is uitgevoerd. Reviewen is haast onmogelijk
> en volgens mij mankeert hier nogal wat aan..

Ik was idd een beetje snel met het toepassen; ik was vol vertrouwen ;-). Voel je
vrij om je opmerkingen nog te plaatsen hier, dan verwerk ik die alsnog (of maak
er zelf een patch van)
> #define MSG_STATUS_DL %s aan %.2f KB/sec (%u KB van %u KB gedownload)
> #define MSG_STATUS_DL %s met %.2f KB/sec (%u KB van %u KB gedownload)
> Deze had ik dus net ervoor in de omgekeerde richting veranderd.  Je fietst toch
> aan 20km/u en niet met 20km/u?

Uh, nee. Aan, dat zal dan wel iets Vlaams zijn...


> En hoe komt het dat jouw ï's als ï verschijnen terwijl de mijne wel er gewoon
> als ï uitzien?

Omdat jouw files blijkbaar niet UTF-8 (Unicode) gecodeerd zijn? De tekenset van
Bugzilla is Latin-1, en in die representatie ziet een ï in UTF-8 eruit als ï.
Zo niet, dan is de tekenset van de patch ook Latin-1.


> #define MB_ATTENTION_STR Attentie
> Wat is er mis met aandacht?????

Ik ben het er mee eens dat Attentie een betere vertaling is. Aandacht is gewoon
niet het juiste woord, als je om attentie vraagt zeg je ‘Attentie’ en niet
‘Aandacht’, alhoewel dat laatste niet per sé fout zou zijn (maar wel
ongebruikelijk)...


~Grauw
(In reply to comment #19)
> > #define MSG_STATUS_DL %s aan %.2f KB/sec (%u KB van %u KB gedownload)
> > #define MSG_STATUS_DL %s met %.2f KB/sec (%u KB van %u KB gedownload)
> > Deze had ik dus net ervoor in de omgekeerde richting veranderd.  Je fietst toch
> > aan 20km/u en niet met 20km/u?
> 
> Uh, nee. Aan, dat zal dan wel iets Vlaams zijn...

Hm, mijn Duitse collega zegt dat het in het Duits ook `mit' is.
En inderdaad, alle Google-resultaten op "met 25 km/u" komen van .be-sites. 
Tsja, maak er dan maar weer aan van :-(

> > En hoe komt het dat jouw ï's als ï verschijnen terwijl de mijne wel er gewoon
> > als ï uitzien?
> 
> Omdat jouw files blijkbaar niet UTF-8 (Unicode) gecodeerd zijn? De tekenset van
> Bugzilla is Latin-1, en in die representatie ziet een ï in UTF-8 eruit als ï.
> Zo niet, dan is de tekenset van de patch ook Latin-1.

Ok, ik heb mijn hele CVS-project naar UTF-8 omgeschakeld

> > #define MB_ATTENTION_STR Attentie
> > Wat is er mis met aandacht?????
> 
> Ik ben het er mee eens dat Attentie een betere vertaling is. Aandacht is gewoon
> niet het juiste woord, als je om attentie vraagt zeg je ‘Attentie’ en niet
> ‘Aandacht’, alhoewel dat laatste niet per sé fout zou zijn (maar wel
> ongebruikelijk)...

Hm, als ik om aandacht vraag, dan zeg ik aandacht.  Zal wel weer zo'n geval à la
jus d'orange vs. appelsiensap zijn. 

Zoals steeds: het zijn maar bedenkingen van mijn kant, jullie zijn vrij om ermee
te doen wat jullie willen.  Hetzelfde geldt voor mijn patches.
Is het zinvol om aan het gedeelte nl/editor nog te werken?  Ik heb het gevoel
dat dit niet echt meer gebruikt wordt, nu de Suite niet meer ondersteund wordt.
 Of heb ik het mis?

En daarop aansluitend: is het belangrijk dat de bestanden in dezelfde volgorde
staan van de Engelse?  Behalve voor de overzichtelijkheid zal dat wel niet erg
zinvol zijn, veronderstel ik.
(In reply to comment #20)
> > > #define MSG_STATUS_DL %s aan %.2f KB/sec (%u KB van %u KB gedownload)
> > > #define MSG_STATUS_DL %s met %.2f KB/sec (%u KB van %u KB gedownload)
> > > Deze had ik dus net ervoor in de omgekeerde richting veranderd.  Je fietst
toch
> > > aan 20km/u en niet met 20km/u?
> > 
> > Uh, nee. Aan, dat zal dan wel iets Vlaams zijn...
> 
> Hm, mijn Duitse collega zegt dat het in het Duits ook `mit' is.
> En inderdaad, alle Google-resultaten op "met 25 km/u" komen van .be-sites. 
> Tsja, maak er dan maar weer aan van :-(

Ter verduidelijking: ik bedoelde dat het MET moet zijn, niet AAN.


> Hm, als ik om aandacht vraag, dan zeg ik aandacht.  Zal wel weer zo'n geval à la
> jus d'orange vs. appelsiensap zijn. 

Sinaasappelsap bedoel je ;p.


~Grauw
(In reply to comment #17)
> #define TYPE_CUSTOM_DESC U kunt individuele onderdelen kiezen om te worden
> geïnstalleerd. Aanbevolen voor ervaren gebruikers.
> Dit vind ik een beetje krom Nederlands.  worden geïnstalleerd -> installeren is
> beter, maar nog beter: u kunt kiezen welke (individuele) onderdelen worden
> geïnstalleerd (rode volgorde toch?), waar ik individuele zou weglaten wegens
> overbodig.

Zat mij ook niet lekker, ik maak er wel het tweede van. 'Individule' past ook
meer bij 'options', wat hier overigens een wat vreemde term is.
 
> #define DL_FILENAME Nu downloadend:
> Dat vind ik echt niet mooi hoor.  Wie gebruikt er tegenwoordig nog onvoltooid
> deelwoord...  Veel te letterlijke vertaling van now downloading.  Ik vind
> Bestand: zoals het er stond best wel een goede oplossing.
> #define INSTALL_STATUSCOMP Nu installerend: 
> idem

Tja, wat is mooi.. Ik vind er persoonlijk niet zo veel mis mee. 'Nu aan het
downloaden/installeren:' kan ook maar had niet mijn voorkeur, en 'Bestand:' zegt
helaas niets over de status, dus wat ermee wordt gedaan. In FF/TB wordt deze
werkwoordsvorm geloof ik over het algemeen vermeden en dat kan ook vaak heel
goed, maar is het erg om hem voor de installer wel te gebruiken?

> Deze had ik dus net ervoor in de omgekeerde richting veranderd.  Je fietst toch
> aan 20km/u en niet met 20km/u?

Nederlanders rijden idd _met_ een bepaalde snelheid, evenals de Duitsers. Alleen
rijden die vaak wat harder. ;)

> Het is het
> installatieprogramma dat ervan uitgaaT dat, niet de andere modi die ervan
> uitgaaN dat (redelijk tegen het einde)

"All other modes: assume user wants to cleanup.."

Ik ben bang dat hier toch echt de (stille en automatische) modi worden bedoeld
die ergens van uitgaan.

> Overigens twijfel ik of we niet NORMAL
> modus moeten schrijven i.p.v. NORMALE (iets soortgelijks aan method i.p.v.
methode)

NORMALE is hier geen attribuut o.i.d. maar een b.n., evenals 'stille' en
'automatische'. Termen als 'hideBanner' en 'showBanner' zijn opties, geen modi.

> > P.S. Jammer dat att. 193797 zo snel is uitgevoerd. Reviewen is haast onmogelijk
> > en volgens mij mankeert hier nogal wat aan..
> 
> Ja, ik vond het ook al snel gaan.  Maar niemand houdt je tegen om net als
> hierboven al mijn wijzigingen weer ongedaan te maken :-p

Het is natuurlijk omslachtig om jouw uitgevoerde patches te gaan doorspitten op
wijzigingen en die eventueel ongedaan te maken, vooral omdat het herindelen van
de bestanden nalopen ervan voor een ander wat lastig maakt, dus misschien dat je
er zelf nog even doorheen kan lopen? Zo 1, 2, 3 zag ik nog een aantal keer
'ontleedfout' staan (moet dat niet overal 'parsefout' worden?), Thai is toch
echt Thai, en voor de é geldt hetzelfde als de ë.
Attached patch Installer (2) (obsolete) — — Splinter Review 
Gewijzigd.
Attachment #193802 - Attachment is obsolete: true
(In reply to comment #23)
> (In reply to comment #17)
> > #define DL_FILENAME Nu downloadend:
> > Dat vind ik echt niet mooi hoor.  Wie gebruikt er tegenwoordig nog onvoltooid
> > deelwoord...  Veel te letterlijke vertaling van now downloading.  Ik vind
> > Bestand: zoals het er stond best wel een goede oplossing.
> > #define INSTALL_STATUSCOMP Nu installerend: 
> > idem
> 
> Tja, wat is mooi.. Ik vind er persoonlijk niet zo veel mis mee. 'Nu aan het
> downloaden/installeren:' kan ook maar had niet mijn voorkeur, en 'Bestand:' zegt
> helaas niets over de status, dus wat ermee wordt gedaan. 

Is er niet een venstertiteltje dat zegt dat je aan het downloaden bent?  Of
anders gewoon de d weglaten?

> > Deze had ik dus net ervoor in de omgekeerde richting veranderd.  Je fietst toch
> > aan 20km/u en niet met 20km/u?
> 
> Nederlanders rijden idd _met_ een bepaalde snelheid, evenals de Duitsers. Alleen
> rijden die vaak wat harder. ;)

:-) Zie boven, alwaar ik verstrooid was en dus bedoelde: maak er maar `aan' van.

> > Het is het
> > installatieprogramma dat ervan uitgaaT dat, niet de andere modi die ervan
> > uitgaaN dat (redelijk tegen het einde)
> 
> "All other modes: assume user wants to cleanup.."
> 
> Ik ben bang dat hier toch echt de (stille en automatische) modi worden bedoeld
> die ergens van uitgaan.

Neen.  Iedere beschrijving van een optie begint met een infinitief, ter
verklaring wat die optie doet.  Dit is net zo'n infinitief, die verklaart wat er
gebeurt als je niet in NORMALE modus bent.
 
> > Overigens twijfel ik of we niet NORMAL
> > modus moeten schrijven i.p.v. NORMALE (iets soortgelijks aan method i.p.v.
> methode)
> 
> NORMALE is hier geen attribuut o.i.d. maar een b.n., evenals 'stille' en
> 'automatische'. Termen als 'hideBanner' en 'showBanner' zijn opties, geen modi.

Ik snap het verschil wel, maar omdat het in hoofdletters staat had ik het gevoel
dat het misschien iets commandline-achtigs is, en dus onvertaald moet blijven.

> Het is natuurlijk omslachtig om jouw uitgevoerde patches te gaan doorspitten op
> wijzigingen en die eventueel ongedaan te maken, vooral omdat het herindelen van
> de bestanden nalopen ervan voor een ander wat lastig maakt, dus misschien dat je
> er zelf nog even doorheen kan lopen?

Natuurlijk is het niet de bedoeling dat dit iedere keer zo gaat...

> Zo 1, 2, 3 zag ik nog een aantal keer
> 'ontleedfout' staan (moet dat niet overal 'parsefout' worden?), Thai is toch
> echt Thai, en voor de é geldt hetzelfde als de ë. 

é heb ik al overal vervangen, evenals ontleedfout.  Dat komt er dus in een
volgende patch automatisch bij.
Hier: http://europa.eu.int/comm/translation/currencies/nltable1.htm zijn ze het
niet met je eens.  Thai is de aanduiding voor de inwoner, en Engels.  Voor  het
bn moet er een s achter.  Maar Wikipedia schijnt te vinden dat de taal wel Thai
is.  Lijkt mij een besmetting van het Engels, maar goed, ik leg er me bij neer.

(In reply to comment #24)
> Created an attachment (id=194020) [edit]
> Installer (2)
> 
> Gewijzigd.

Zie mijn commentaar hierboven, rond installeren(d) en de command-lineopties
Enkele fouten en verbeteringen voor het venstertje: > Bestand > Offline > Nu
downloaden/synchoniseren
(In reply to comment #27)
> Created an attachment (id=194524) [edit]
> Verbeteringen voor het Offline > Synchroniseren venster
> 
> Enkele fouten en verbeteringen voor het venstertje: > Bestand > Offline > Nu
> downloaden/synchoniseren

offline gebruik of offline-gebruik? (Wat mij betreft: offlinegebruik)

de &quot;Selecteren&quot; knop: Liever de knop "Selecteren",  (het is een dtd,
dus je mag gerust " gebruiken), maar als je die volgorde wil houden, dan zeker
een streepje.

Zeker dat het `het volgende' moet zijn?  

Verder top.

(In reply to comment #28)
> de &quot;Selecteren&quot; knop: Liever de knop "Selecteren",  (het is een dtd,
> dus je mag gerust " gebruiken)

wat is er mis met &quot;Selecteren&quot;?


(In reply to comment #29)
> (In reply to comment #28)
> > de &quot;Selecteren&quot; knop: Liever de knop "Selecteren",  (het is een dtd,
> > dus je mag gerust " gebruiken)
> 
> wat is er mis met &quot;Selecteren&quot;?

Niks natuurlijk, ik wou alleen maar aangeven, dat het niet nodig is &quot; te
schrijven, daar .dtd's UTF-8 gecodeerd zijn en dus even goed `"' kunnen
bevatten.  Het ging mij om de combinatie `de &quot;Selecteren&quot; knop', daar
moet ofwel een streepje in, of, liever omgedraaid worden.
(In reply to comment #25)
> 
> Is er niet een venstertiteltje dat zegt dat je aan het downloaden bent?  Of
> anders gewoon de d weglaten?

Ik dacht van niet, maar ik vind niet dat er een taboe heerst op deze
werkwoordsvorm en hou het dus liever zo (net als in TB overigens, voor het geval
het nog niet was opgevallen), tenzij er nog meer gegronde bezwaren zijn.
 
> :-) Zie boven, alwaar ik verstrooid was en dus bedoelde: maak er maar `aan' van.

Net als hier waarschijnlijk. :)

> Neen.  Iedere beschrijving van een optie begint met een infinitief, ter
> verklaring wat die optie doet.  Dit is net zo'n infinitief, die verklaart wat er
> gebeurt als je niet in NORMALE modus bent.

Wellicht heb je ook gezien dat er ondanks 'prompt' en 'assume' in de Engelse
tekst noch daar, noch in het Nederlands consistent een infinitief voor de opties
wordt gebruikt (als die al als zodanig te herkennen is) maar daar gaat het hier
niet echt om, al begrijp ik wel je punt. De werkwoordsvorm lijkt per optie
willekeurig te zijn (points to / Tells Setup to / Show) en misschien was daarom
ook 'prompt' in 'NORMAL mode: prompt user..' wel vertaald met 'vraagt', los van
het feit dat commandline-opties in het Nederlands meestal in 3e persoon ev
worden geschreven. Belangrijker zijn de lange optiebeschrijvingen met daarin
meerdere condities, waarin 'de optie' of iets vervangends als bv. 'dit' voor het
onderwerp in beide gevallen uitblijft in een nieuwe conditie, zin en zelfs na
een dubbele punt. Dit zorgt ervoor dat de modi in deze 'subgevallen' als
onderwerp kunnen worden gehanteerd i.p.v. het blijvend toe te wijzen aan de
optie (en niet het installatieprogramma overigens, hoewel ook daarover valt te
twisten). Aangezien de modi condities en daarmee bepalend zijn is dat
taaltechnisch goed mogelijk en staat het iets beter, zo leek me. M.a.w., de
optie -cleanupOnUpgrade _vertelt_ dan alleen iets, terwijl de modi bepalen of er
al dan niet iets gewist moet worden en daardoor ook _uitgaan van_ etc., zelfs al
geldt dat eigenlijk nog steeds voor de optie. Blijft de laatste in alle gevallen
het onderwerp en de modus alleen een conditie dan is 'vraagt' uiteraard op zijn
plaats, maar dit ziet er dus wat vreemd uit. Duidelijker zou het zijn als er
'in' voor zowel de normale als de andere modi had gestaan of daadwerkelijk een
infinitief werd gebruikt, alhoewel het laatste niet is aan te raden. Hoe dan
ook, aangezien het toch een soort smokkelen is wil ik me wel neerleggen bij de
huidige vorm als er meer bezwaren zijn.

Als je overigens tegen deze redenatie in wilt gaan vind ik het prima (alhoewel
onnodig), maar ik wil het hier in deze bug graag bij laten. Meld je liever eens
op IRC als je houdt van lang twisten over 1-lettergevallen als deze, al zit men
er daar ook niet op te wachten.. :)

> é heb ik al overal vervangen, evenals ontleedfout.  Dat komt er dus in een
> volgende patch automatisch bij.

Ik zie nog steeds trema's, accenten en 'ontleedfout' in de cvs. Als je bedoelt
dat je dit laat zitten tot in een volgende patch dan zou ik daar om praktische
redenen niet langer mee wachten, of liever eerst deze zaken z.s.m. in orde
maken, ook omdat het geïntroduceerde fouten zijn in je vorige patch. Daarbij, en
dat is misschien belangrijker, zal het niet de eerste keer zijn dat ineens een
FF-versie wordt uitgebracht terwijl de tekst nog niet 100% is, al is dat
misschien een utopie.

> Hier: http://europa.eu.int/comm/translation/currencies/nltable1.htm zijn ze het
> niet met je eens.  Thai is de aanduiding voor de inwoner, en Engels.  Voor  het
> bn moet er een s achter.  Maar Wikipedia schijnt te vinden dat de taal wel Thai
> is.  Lijkt mij een besmetting van het Engels, maar goed, ik leg er me bij neer.

Thai is idd de taal, Thais het b.n. In FF gaat het om de taal.

P.S. Ben na vandaag weer aantal dagen weg. Patch graag z.s.m. uitvoeren.

(In reply to comment #27)
Over msgSynchronize.dtd: het is idd 'offline-gebruik' en 'knop
&quot;Selecteren&quot;', en waarschijnlijk ook 'de volgende'. &quot;'s graag
behouden aangezien ze ook worden gebruikt in het Engels. Verder mag (/moet?)
'en' in MsgSyncDirections.label 'en/of' worden, en syncTypeMail.accesskey een E.
Bestand was overigens niet meegenomen omdat ik dacht dat het niet meer werd
gebruikt.
(In reply to comment #31)
> (In reply to comment #25)
> > :-) Zie boven, alwaar ik verstrooid was en dus bedoelde: maak er maar `aan' van.
> 
> Net als hier waarschijnlijk. :)

Brr, ja, ik heb er blijkbaar onbewust zo veel moeite mee...

> > Neen.  Iedere beschrijving van een optie begint met een infinitief, ter

irc.mozilla.org #mozilla.nl, veronderstel ik?  vanaf nu aanwezig!

> > é heb ik al overal vervangen, evenals ontleedfout.  Dat komt er dus in een
> > volgende patch automatisch bij.
> 
> Ik zie nog steeds trema's, accenten en 'ontleedfout' in de cvs. Als je bedoelt
> dat je dit laat zitten tot in een volgende patch dan zou ik daar om praktische
> redenen niet langer mee wachten, of liever eerst deze zaken z.s.m. in orde
> maken, ook omdat het geïntroduceerde fouten zijn in je vorige patch. Daarbij, en
> dat is misschien belangrijker, zal het niet de eerste keer zijn dat ineens een
> FF-versie wordt uitgebracht terwijl de tekst nog niet 100% is, al is dat
> misschien een utopie.

Ok, ik maak een aparte patch.
Eerste snelle vertaling van twee nieuwe bestanden.  Misschien moet programma
toepassing worden, ik vind dit laatste woord er echter met de haren
bijgesleept.
(In reply to comment #32)
> (In reply to comment #31)
> > (In reply to comment #25)
> > > é heb ik al overal vervangen, evenals ontleedfout.  Dat komt er dus in een
> > > volgende patch automatisch bij.
> > 
> > Ik zie nog steeds trema's, accenten en 'ontleedfout' in de cvs. Als je bedoelt
> > dat je dit laat zitten tot in een volgende patch dan zou ik daar om praktische
> > redenen niet langer mee wachten, of liever eerst deze zaken z.s.m. in orde
> > maken, ook omdat het geïntroduceerde fouten zijn in je vorige patch. Daarbij, en
> > dat is misschien belangrijker, zal het niet de eerste keer zijn dat ineens een
> > FF-versie wordt uitgebracht terwijl de tekst nog niet 100% is, al is dat
> > misschien een utopie.
> 
> Ok, ik maak een aparte patch.

Ik was hiermee bezig, maar in xslt.properties staat ook ontleedfout, hoewel ik
die daar niet zelf geïntroduceerd heb.  Zal ik deze ook wijzigen?
Attached file Fouten in nl (obsolete) — 
In de nieuwsgroep netscape.public.mozilla.l10n was te lezen over een
controletool voor l10n bestanden en de maker had de tool over alle vertalingen
in CVS heengehaald. Dit is het resultaat ervan. Als iemand een patch kan maken
om de fouten eruit te halen, graag.
(In reply to comment #35)
> Created an attachment (id=195124) [edit]
> Fouten in nl
> 
> In de nieuwsgroep netscape.public.mozilla.l10n was te lezen over een
> controletool voor l10n bestanden en de maker had de tool over alle vertalingen
> in CVS heengehaald. Dit is het resultaat ervan. Als iemand een patch kan maken
> om de fouten eruit te halen, graag.

controleer wel of de fouten nog bestaan in de cvs oftewel zorg dat je met een
geudate versie werkt!

Comment on attachment 194864 [details] [diff] [review]
De vertalingen van de nieuwe map Overrides

toegepast op branch en trunk
Attachment #194864 - Attachment is obsolete: true
Bij het aanpassen van de helpbestanden stootte ik op een probleempje: een bugfix
die alleen in de trunk is doorgevoerd, niet in de MOZILLA_1_8_BRANCH van de
Engelse versie.  Moet ik die nu hier ook doorvoeren of niet?  Of beter gezegd,
in bug 293223 (ik vraag het hier vanwege nieuwe versie)

En hoe zat het nu met ontleedfout?  Houden of niet?
(In reply to comment #38)
> Bij het aanpassen van de helpbestanden stootte ik op een probleempje: een bugfix
> die alleen in de trunk is doorgevoerd, niet in de MOZILLA_1_8_BRANCH van de
> Engelse versie.  Moet ik die nu hier ook doorvoeren of niet?  Of beter gezegd,
> in bug 293223 (ik vraag het hier vanwege nieuwe versie)
> 
> En hoe zat het nu met ontleedfout?  Houden of niet?

wees even wat duidelijker, om welke bugfix gaat het?

ontleedfout vervangen.

Tim Maks
(In reply to comment #39)
> (In reply to comment #38)
> wees even wat duidelijker, om welke bugfix gaat het?

Het gaat om de wijzigingen aan shortcuts.xhtml: daar zijn wijzigingen
aangebracht in de HEAD, maar niet in de MOZILLA_1_8_BRANCH, zie
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=&branchtype=match&dir=&file=mozilla%2Fbrowser%2Flocales%2Fen-US%2Fchrome%2Fhelp%2Fshortcuts.xhtml&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot

> ontleedfout vervangen.

ok.
(In reply to comment #40)
> (In reply to comment #39)
> > (In reply to comment #38)
> > wees even wat duidelijker, om welke bugfix gaat het?
> 
> Het gaat om de wijzigingen aan shortcuts.xhtml: daar zijn wijzigingen
> aangebracht in de HEAD, maar niet in de MOZILLA_1_8_BRANCH, zie
>
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=&branchtype=match&dir=&file=mozilla%2Fbrowser%2Flocales%2Fen-US%2Fchrome%2Fhelp%2Fshortcuts.xhtml&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=all&mindate=&maxdate=&cvsroot=%2Fcvsroot
> 
in de genoemde bugs wavhten ze op toestemming om het ook in de branch te
vervangen. mijn suggestie is maak de patch maar zet bij de opmerkingen dat het
momenteel alleen voor de trunk is.
Verbeteringen voor Firefox en Thunderbird. Veel nav de foutcontrole, maar ook
wat andere kleine dingen die ik tegenkwam. De enige 'fout' die ik heb laten
zitten is Nu herstarten. Ik weet niet of dit met opzet is gedaan en imo voegt
de productnaam hier niet zoveel toe. Het maakt het label alleen maar langer.

Tim Maks: Wat is er eigenlijk aan de hand met de help? Het lijkt me goed dat
dit een getest gaat worden, verder lijkt de vertaling me eigenlijk af.
(In reply to comment #42)
> Created an attachment (id=195517) [edit]
> Verbeteringen, oa veel vanwege foutcontrole

<!ENTITY credit.translation
dankjewel ;-)

+++ browser/installer/installer.inc	10 Sep 2005 08:37:31 -0000
@@ -1,4 +1,4 @@
-#filter emptyLines
+#filter emptyLines

is dit de bedoeling?  Lijkt me een BOM?

-<!ENTITY  brandFullName         "Mozilla Thunderbird Alpha 2">
+<!ENTITY  brandFullName         "Mozilla Thunderbird">

Is dit niet iets om pas helemaal op het laatste te doen?  Ik vind het wel handig
om te zien welke versie ik aan het draaien ben...

Overigens, is iemand er al in geslaagd om twee versies van TB tegelijk te laten
lopen?  Sinds ik de nightly geïnstalleerd heb, doet 1.0.6 het niet meer.

> Tim Maks: Wat is er eigenlijk aan de hand met de help? Het lijkt me goed dat
> dit een getest gaat worden, verder lijkt de vertaling me eigenlijk af.

Idd, dat lijkt niet te werken in de nightly's.

(In reply to comment #43)
> +++ browser/installer/installer.inc	10 Sep 2005 08:37:31 -0000
> @@ -1,4 +1,4 @@
> -#filter emptyLines
> +#filter emptyLines
> 
> is dit de bedoeling?  Lijkt me een BOM?
nee. Hier is wat foutgegaan. Waarschijnlijk foutgegaan, omdat ik het tussendoor
nog in Kladblok geopend heb...
> 
> -<!ENTITY  brandFullName         "Mozilla Thunderbird Alpha 2">
> +<!ENTITY  brandFullName         "Mozilla Thunderbird">
> 
> Is dit niet iets om pas helemaal op het laatste te doen?  Ik vind het wel handig
> om te zien welke versie ik aan het draaien ben...
Dat is waar, maar dan zouden we het moeten veranderen naar Beta1. Vind ik opzich
ook goed. Alpha2 is sowieso achterhaald en ik wilde het weghalen om het te
synchroniseren met de Engelse versie.
> Overigens, is iemand er al in geslaagd om twee versies van TB tegelijk te laten
> lopen?  Sinds ik de nightly geïnstalleerd heb, doet 1.0.6 het niet meer.
Ik heb wel een aantal keer nightlies van Thunderbird getest, maar dan in een los
profiel. Dat leverde geen problemen op. 

Wil je ze trouwens naast elkaar gebruiken, of ook 2 verschillende versies van
Thunderbird tegelijkertijd open hebben? Voor dat laaste kun je ook
http://home.hccnet.nl/e.vd.beek/blog/2005/06/2-verschillende-firefox-versies.html
proberen.
> > Tim Maks: Wat is er eigenlijk aan de hand met de help? Het lijkt me goed dat
> > dit een getest gaat worden, verder lijkt de vertaling me eigenlijk af.
> 
> Idd, dat lijkt niet te werken in de nightly's.
Ik merkte toestraks dat alle vertaalde nightlies hier problemen mee hebben. Ik
neem aan dat er al een bug voor dit probleem is.
(In reply to comment #44)
> Ik heb wel een aantal keer nightlies van Thunderbird getest, maar dan in een los
> profiel. Dat leverde geen problemen op. 
> 
> Wil je ze trouwens naast elkaar gebruiken, of ook 2 verschillende versies van
> Thunderbird tegelijkertijd open hebben? Voor dat laaste kun je ook
> http://home.hccnet.nl/e.vd.beek/blog/2005/06/2-verschillende-firefox-versies.html
> proberen.

Dat heb ik al goed bekeken voor FF, en daarmee is het gelukt, maar hetzelfde
trucje met TB lijkt niet te werken.  De oude komt niet meer verder dan vragen
welk profiel ik wil gebruiken, en dan niks meer.  Nu ja, ik gebruike nu dan maar
gewoon de nieuwe, niks aan te doen.
(In reply to comment #45)
> Dat heb ik al goed bekeken voor FF, en daarmee is het gelukt, maar hetzelfde
> trucje met TB lijkt niet te werken.  De oude komt niet meer verder dan vragen
> welk profiel ik wil gebruiken, en dan niks meer.  Nu ja, ik gebruike nu dan maar
> gewoon de nieuwe, niks aan te doen.
Het lukte bij mij gewoon wel. Ik had het profiel van te voren al aangemaakt en
na SET... kon ik via thunderbird -p Test Beta 1 opstarten naast 1.0.6.
Comment on attachment 195517 [details] [diff] [review]
Verbeteringen, oa veel vanwege foutcontrole

patch is toegepast in de trunk en de branch.
Attachment #195517 - Attachment is obsolete: true
(In reply to comment #24)
> Created an attachment (id=194020) [edit]
> Installer (2)
> 
> Gewijzigd.

Kan iemand mij vertellen wat de status van deze patch is. Door de vele
opmerkingen /discussies weet ik niet meer of ik deze zal toepassen of dat er een
nieuwe komt.


Comment on attachment 194524 [details] [diff] [review]
Verbeteringen voor het Offline > Synchroniseren venster

toegepast op de branch en trunk met de opmerking van Hendrik verwerkt (knop)
Attachment #194524 - Attachment is obsolete: true
(In reply to comment #43)

> 
> -<!ENTITY  brandFullName         "Mozilla Thunderbird Alpha 2">
> +<!ENTITY  brandFullName         "Mozilla Thunderbird">
> 
> Is dit niet iets om pas helemaal op het laatste te doen?  Ik vind het wel handig
> om te zien welke versie ik aan het draaien ben...

de versie wordt nu op een andere plek ingevoegd dus je zal blijven zien welke
versie je draait. 

> > Tim Maks: Wat is er eigenlijk aan de hand met de help? Het lijkt me goed dat
> > dit een getest gaat worden, verder lijkt de vertaling me eigenlijk af.
> 
> Idd, dat lijkt niet te werken in de nightly's.
> 
ik ben al een aantal dagen bezig om het probleem met de help optelossen (zie de
bonsailog ;-) ) ga nu kijken hoe het in andere locales is en als het daar ook
voorkomt zal ik een bug aanmaken.

Comment on attachment 195124 [details]
Fouten in nl

deze fouten lijst is verwerkt door een patch van PW
Attachment #195124 - Attachment is obsolete: true
(In reply to comment #50)

> ik ben al een aantal dagen bezig om het probleem met de help optelossen (zie de
> bonsailog ;-) ) ga nu kijken hoe het in andere locales is en als het daar ook
> voorkomt zal ik een bug aanmaken.
> 
ik denk dat ik de fout heb gevonden :-)


(In reply to comment #52)
> ik denk dat ik de fout heb gevonden :-)

Mooi zo!  

Maar ik meen te zien dat je alle afbeeldingen verwijderd hebt, dat is een beetje
voorbarig.  Onder andere urlbar.png, searchbar.png, next.png, previous.png,
last.png en first.png worden nog gebruikt, evenals pg-portrait-small.png en
pg-landscape-small.png.  Ik denk dat dat alles is (en allemaal in
using-firebird.xhtml, dus ik heb zo een vermoeden dat die er misschien ook nog
worden uitgehaald).
(In reply to comment #53)
> (In reply to comment #52)
> > ik denk dat ik de fout heb gevonden :-)
> 
> Mooi zo!  
> 
> Maar ik meen te zien dat je alle afbeeldingen verwijderd hebt, dat is een beetje
> voorbarig.  Onder andere urlbar.png, searchbar.png, next.png, previous.png,
> last.png en first.png worden nog gebruikt, evenals pg-portrait-small.png en
> pg-landscape-small.png.  Ik denk dat dat alles is (en allemaal in
> using-firebird.xhtml, dus ik heb zo een vermoeden dat die er misschien ook nog
> worden uitgehaald).


dan was de patch van Gert Paul te voorbarig. Hij had ze uit de lijst
extra-jar.mn gehaald dus worden ze niet meer gebruikt bij het bouwen. ik zal de
afbeeldingen die jij noemt terug plaatsen.
(In reply to comment #54)
> dan was de patch van Gert Paul te voorbarig. Hij had ze uit de lijst
> extra-jar.mn gehaald dus worden ze niet meer gebruikt bij het bouwen. ik zal de
> afbeeldingen die jij noemt terug plaatsen.
De afbeeldingen die ik uit extra-ja.msn heb gehaald konden ook weg, maar niet
alles stond daar idd in. Voor die afbeeldingen moeten dus nieuwe regels aan
extra-jar.mn toegevoegd worden en de afbeeldingen die Hendrik noemde moeten
teruggeplaatst worden.
Hmm ik had beter moeten kijken. Deze afbeeldingen kwamen orgineel al niet voor
in die lijst (sorry Gert Paul). Ik heb ze terug geplaatst, ben benieuwd of ze
dan wel meegenomen worden in de build.
(In reply to comment #55)
> (In reply to comment #54)
> > dan was de patch van Gert Paul te voorbarig. Hij had ze uit de lijst
> > extra-jar.mn gehaald dus worden ze niet meer gebruikt bij het bouwen. ik zal de
> > afbeeldingen die jij noemt terug plaatsen.
> De afbeeldingen die ik uit extra-ja.msn heb gehaald konden ook weg, maar niet
> alles stond daar idd in. Voor die afbeeldingen moeten dus nieuwe regels aan
> extra-jar.mn toegevoegd worden en de afbeeldingen die Hendrik noemde moeten
> teruggeplaatst worden.

mid air :-)

wil jij die afbeeldingen dan even toevoegen aan de lijst zodat ze meegaan in de
build van vanavond. Ik moet nu echt weg

(In reply to comment #57)
> (In reply to comment #55)
> wil jij die afbeeldingen dan even toevoegen aan de lijst zodat ze meegaan in de
> build van vanavond. Ik moet nu echt weg
Ja, is gebeurd.
Ik heb de hele submap editor bekeken.  De bestanden die nog niet vertaald waren
heb ik vertaald, naar mijn beste kunnen zoals altijd (Hoe vertaal je snap to
grid?).  De bestanden die al vertaald waren, waren meestal alfabetisch
gesorteerd, wat het wat moeilijk maakt om deze up to date te houden, dus die
heb ik weer in dezelfde volgorde als de Engelse geplaatst, en ook af en toe een
woordje veranderd.

Ik heb zo het gevoel dat vele bestanden niet meer gebruikt worden, maar het
werk is nu toch gedaan, dus kan het even goed toegepast worden...
Attached patch patch voor editor.properties (obsolete) — — Splinter Review 
Opgepast, editor.properties in de vorige patch is niet ok, daar staat ruis
tussen veroorzaakt door rcsmerge.  Deze is de goeie.  Overigens de opmerking
dat de vorige patch gemaakt is vanuit de map editor, deze vanuit nl.
Verandert voor in van zodat het weer in het menu past. De regel was een letter
te lang.
(In reply to comment #61)
> Created an attachment (id=195888) [edit]
> Bladwijzer voor => Bladwijzer van
> 
> Verandert voor in van zodat het weer in het menu past. De regel was een letter
> te lang.

Kan je niet gewoon de grootte van het venster aanpassen?
(In reply to comment #62)
> 
> Kan je niet gewoon de grootte van het venster aanpassen?
Het gaat om een menu (Bladwijzers). Aanpassen van de grootte is dus wat makkelijker.

Bladwijzer van vind ik trouwens wel beter klinken dan Bladwijzer voor, maar
blijkbaar vindt jij dat niet?
(In reply to comment #62)
> (In reply to comment #61)
> > Created an attachment (id=195888) [edit] [edit]
> > Bladwijzer voor => Bladwijzer van
> > 
> > Verandert voor in van zodat het weer in het menu past. De regel was een letter
> > te lang.
> 
> Kan je niet gewoon de grootte van het venster aanpassen?

de breedte van een menu kunnen we niet aanpassen, helaas. Daar zit een maximum
aan. Maar wat is er mis met de verandering?

(In reply to comment #63)
> (In reply to comment #62)
> > 
> > Kan je niet gewoon de grootte van het venster aanpassen?
> Het gaat om een menu (Bladwijzers). Aanpassen van de grootte is dus wat
makkelijker.
> 
> Bladwijzer van vind ik trouwens wel beter klinken dan Bladwijzer voor, maar
> blijkbaar vindt jij dat niet?

Euh, eigenlijk... kweenie, beide vallen te verdedigen, maar van klinkt vlotter, ja.

(In reply to comment #64)
> (In reply to comment #62)
> > (In reply to comment #61)
> > > Created an attachment (id=195888) [edit] [edit] [edit]
> > > Bladwijzer voor => Bladwijzer van
> > > 
> > > Verandert voor in van zodat het weer in het menu past. De regel was een letter
> > > te lang.
> > 
> > Kan je niet gewoon de grootte van het venster aanpassen?
> 
> de breedte van een menu kunnen we niet aanpassen, helaas. Daar zit een maximum
> aan. Maar wat is er mis met de verandering?

Niks dus.  Ik vroeg het me gewoon af.  Ik heb bv. net een wijziging gemaakt om
de thema- en extensiebeheerder breder te laten opstarten, omdat daar de
schuifbalk initieel buiten het venster valt, en ik dacht dat dat hier misschien
ook mogelijk zou zijn


Comment on attachment 195888 [details] [diff] [review]
Bladwijzer voor => Bladwijzer van

toegepast op branch en trunk
Attachment #195888 - Attachment is obsolete: true
(In reply to comment #48)
> (In reply to comment #24)
> > Created an attachment (id=194020) [edit] [edit]
> > Installer (2)
> > 
> > Gewijzigd.
> 
> Kan iemand mij vertellen wat de status van deze patch is. Door de vele
> opmerkingen /discussies weet ik niet meer of ik deze zal toepassen of dat er een
> nieuwe komt.
> 

In comment 31 heb ik gevraagd hem z.s.m. uit te voeren.. Graag alsnog als dat
kan, al zal dat wel weer problemen geven. :(

(In reply to comment #66)
> (From update of attachment 195888 [details] [diff] [review] [edit])
> toegepast op branch en trunk

Ai, net te laat; ik wou net met klem verzoeken deze niet uit te voeren. Ik had
de enkele voorkomens van 'van' onlangs niet voor niets gewijzigd; een bladwijzer
wordt immers vóór een pagina of koppeling gemaakt en niet ván. Kan je dit nog
ongedaan maken?

Comment on attachment 194020 [details] [diff] [review]
Installer (2)

Wat ik ook probeer, ik krijg de installer patch niet goed toegepast (teveel
verandert in de laatste tijd) Sorry, maar kan je de patch nog een keer maken.
de twee ander bestanden zijn wel gepatched
Attachment #194020 - Attachment is obsolete: true
(In reply to comment #67)

> Ai, net te laat; ik wou net met klem verzoeken deze niet uit te voeren. Ik had
> de enkele voorkomens van 'van' onlangs niet voor niets gewijzigd; een bladwijzer
> wordt immers vóór een pagina of koppeling gemaakt en niet ván. Kan je dit nog
> ongedaan maken?
> 

natuurlijk kan ik die nog ongedaan maken. ik ben niet zo'n help in die kleine
nuances in onze taal maar dit volg ik echt niet. je maakt toch een koppeling van
iets net zoals je een kopie van iets maakt.

blijft het feit dat de regel: Bladwijzer voor deze pagina maken... telang is
voor het menu van Fx.
(In reply to comment #67)

> In comment 31 heb ik gevraagd hem z.s.m. uit te voeren.. Graag alsnog als dat
> kan, al zal dat wel weer problemen geven. :(

ja dat weet ik, ,aar ik heb ook gezien dat er een lange discussie was ontstaan
en dan wil ik van alle partijen weten dat de uitlkomst is, iedereen kan op een
gegeven moment wel roepen dat het snel toegep[ast moet worden ;-) en ik raak
soms het overzicht kwijt.

Zoals je ziet in mijn vorige reactie heb ik vandaag geprobeert je patch toe
tepassen omdat er geen reactie meer kwam op mijn vraag of deze toegepast kon
worden (zwijgen is toestemmen ;-)) Maar helaas heb ik telang gewacht en is je
patch niet meer toepasbaar. Mijn excusses hiervoor, ik heb nog geprobeert met de
hand de patch aantepassen aan de huidige versie maar dat lukte  ook niet. Het
makkelijkste is dat jij een nieuwe maakt vanuit jou lokale versie (merge met de
huidige) en die patch zal ik zo snel mogelijk toepassen. 
Comment on attachment 195772 [details] [diff] [review]
Hele editor opnieuw gerangschikt en vertaald

toegepast op trunk en branch zonder editor.properties
Attachment #195772 - Attachment is obsolete: true
Attached patch Installer (3) (obsolete) — — Splinter Review 
Tegen huidige cvs.
Comment on attachment 195792 [details] [diff] [review]
patch voor editor.properties

toegepast op de branch en de trunk
Attachment #195792 - Attachment is obsolete: true
(In reply to comment #69)
> 
> natuurlijk kan ik die nog ongedaan maken. ik ben niet zo'n help in die kleine
> nuances in onze taal maar dit volg ik echt niet. je maakt toch een koppeling van
> iets net zoals je een kopie van iets maakt.

Je maakt idd een koppeling of een kopie ván iets, maar een bladwijzer vóór,
aangezien dit een boekenlegger (of leeswijzer volgens Van Dale) is: een
markering die ergens wordt aangebracht, en dus niet het te markeren ding zelf,
in dit geval de pagina. Een bladwijzer van iets maken kan wel, maar dan moet dat
een papieren strook of tab o.i.d. zijn, dus de markering.

> blijft het feit dat de regel: Bladwijzer voor deze pagina maken... telang is
> voor het menu van Fx.

In welk menu precies? Ik ben dit nog niet tegengekomen namelijk. Verder vind ik
het doorvoeren van taalcorrecties om deze reden niet zo'n goed idee, hooguit als
het geen afbreuk doet aan de taal en in dit geval gebeurt dat wel, ook al lijkt
het goed te klinken. Beter is het wellicht om een menubreedte aanpasbaar te
laten maken in de source. Als dat niet meer kan vanwege branch-status zou ik
ervoor kiezen om alleen 'van' te gebruiken in dat ene geval en niet overal, en
dan enkel als noodoplossing tot de volgende release.
Comment on attachment 196306 [details] [diff] [review]
Installer (3)

toegepast op trunk en branch
Attachment #196306 - Attachment is obsolete: true
Attached patch Kleine verbeteringen (obsolete) — — Splinter Review 
Dit is een kleine patch met wat verbeteringen. Ik haal ook dictionary.com uit
de zoeklijst, net als in de Engelse versie is gebeurd. Op dit moment ontbrak
het pictogram al.

Moeten we trouwens de zoekplugins nog een keer evalueren en bekijken of alles
relevant is voor een Nederlandse gebruiker en of we toestemming moeten vragen
andere zoekmachines in de lijst toe te voegen?
(In reply to comment #76)
> Created an attachment (id=196347) [edit]
> Kleine verbeteringen
> 
> Dit is een kleine patch met wat verbeteringen. Ik haal ook dictionary.com uit
> de zoeklijst, net als in de Engelse versie is gebeurd. Op dit moment ontbrak
> het pictogram al.

Moet `Zoeken voor' niet `zoeken naar' zijn (search for = zoeken naar)?

> Moeten we trouwens de zoekplugins nog een keer evalueren en bekijken of alles
> relevant is voor een Nederlandse gebruiker en of we toestemming moeten vragen
> andere zoekmachines in de lijst toe te voegen?

Vind ik wel.  Ik vond ze altijd al ontoepasselijk.  Is het bv. geen idee om Van
Dale erin te steken i.p.v. Dictionary?  Niet dat dat zo'n perfecte site is, maar
het is een mooi voorbeeld van wat mogelijk is. Of Wikipedia nl?
Attached patch kleine herformulering (obsolete) — — Splinter Review 
natuurlijkere woordvolgorde, en onnodige witregel weg
Ik dacht dat ik deze al eerder ingegeven had, maar dus blijbaar niet:
verwijdert de é's en ë's uit dom, en ontleedfout -> parsefout
De vensters voor de Extensiebeheerder en de Themabeheerder zijn te klein.  Deze
heb ik wat vergroot.  Het is een nattevingergok, misschien moeten deze waarden
nog wat aangepast worden.

Verder is BrandShortName Thunderbird, niet Mozilla Thunderbird.
(In reply to comment #80)
> Created an attachment (id=196414) [edit]
> vergroot het extensies- en themavenster
> 
> De vensters voor de Extensiebeheerder en de Themabeheerder zijn te klein.  Deze
> heb ik wat vergroot.  Het is een nattevingergok, misschien moeten deze waarden
> nog wat aangepast worden.
> 
> Verder is BrandShortName Thunderbird, niet Mozilla Thunderbird.

Vreemd genoeg lijkt dit in de nieuwste build niet echt nodig, maar ik denk dat
het toch goed is voor als er extensies met lange namen of beschrijvingen
geïnstalleerd worden, anders valt de schuifbalk rechts nl. buiten het venster
(In reply to comment #79)
> Created an attachment (id=196413) [edit]
> speciale tekens verwijderd uit .properties, en ontleedfout
> 
> Ik dacht dat ik deze al eerder ingegeven had, maar dus blijbaar niet:
> verwijdert de é's en ë's uit dom, en ontleedfout -> parsefout

No offense, maar dit werd tijd. :) Zou je ook zaken als Thai e.d. nog willen
herstellen? Verder vanaf nu graag teksten óf herschikken, óf wijzigingen
aanbrengen, en niet allebei tegelijk. Waarom moge duidelijk zijn.

Voornamelijk herschikken van de bestanden zodat ze weer zelfde schikking hebben
als de Engelse.

Hier en daar kon ik het niet laten om een woordje te veranderen (mail opstellen
naar -> mail opstellen aan)

De .properties-bestanden waren al in de goede volgorde, daar heb ik mijn
`gewoonlijke' wijzigingen gemaakt.  En het doet me echt pijn om daar `_het_
zoekfilter' te laten staan, is `de filter' echt uitgesloten daar in het
noorden?
Dit zijn ook voornamelijk herschikkingen, maar toen ik deze deed had ik de
expliciete vraag van Tonnes nog niet gehad, hier heb ik dus vaker wel eens ook
iets gewijzigd, o.a. in de charsets, en standaard browser -> standaardbrowser.
(In reply to comment #82)
> (In reply to comment #79)
> > Created an attachment (id=196413) [edit] [edit]
> > speciale tekens verwijderd uit .properties, en ontleedfout
> > 
> > Ik dacht dat ik deze al eerder ingegeven had, maar dus blijbaar niet:
> > verwijdert de é's en ë's uit dom, en ontleedfout -> parsefout
> 
> No offense, maar dit werd tijd. :) 

Ja, sorry, ik had het al lang aangepast, maar er geen patch van gemaakt.

> Zou je ook zaken als Thai e.d. nog willen
> herstellen? 

Thai zit in de laatste patch verstopt, verder kan ik bij e.d. alleen de
installer-usage bedenken, en dat laat ik voorlopig zo tot we het er eens over
IRC over gehad hebben, want volgens mij is het nog steeds juist in de derde persoon.

(In reply to comment #83)
> De .properties-bestanden waren al in de goede volgorde, daar heb ik mijn
> `gewoonlijke' wijzigingen gemaakt.  En het doet me echt pijn om daar `_het_
> zoekfilter' te laten staan, is `de filter' echt uitgesloten daar in het
> noorden?

Yep. :)


~Grauw

Volgorde aanpassen.

Alleen in composeMsgs.properties heb ik ook wijzigingen aangebracht, omdat het
eerste deel al in de goede volgorde stond, maar de rest niet, had ik niet
gezien.
Attached patch herschikkingen van migration (obsolete) — — Splinter Review 
plus data -> gegevens
De bestanden die nog niet gerangschikt waren aangepast, degene die al in de
juiste volgorde stonden ook soms bewerkt.  Als dus in de patch een min- en een
plus-lijntje onder elkaar staan, dan is dat een wijziging van mij, als het wat
chaotischer is, dan zijn het herschikkingen.
Comment on attachment 196347 [details] [diff] [review]
Kleine verbeteringen

patch toegepast op branch en trunk.

We moeten idd eens de zoekplugins evalueren, open daar maar een nieuwe bug voor
zodat we (als we iets willen veranderen) die kunnen laten reviewen door de QA.
Attachment #196347 - Attachment is obsolete: true
Comment on attachment 196414 [details] [diff] [review]
vergroot het extensies- en themavenster

patch is niet toegepast. Een venster vergroten zonder zelf het eerst te testen
met een schone installatie is niet de goed methode (een venster die je met de
muis groter of kleiner maakt wordt opgeslagen in de instellingen)

brandShortName is wel verandert.
Attachment #196414 - Attachment is obsolete: true
Comment on attachment 196412 [details] [diff] [review]
kleine herformulering

toegepast op branch en trunk
Attachment #196412 - Attachment is obsolete: true
Comment on attachment 196413 [details] [diff] [review]
speciale tekens verwijderd uit .properties, en ontleedfout

patch toegepast op trunk en branch behalve
/l10n/l10n/nl/dom/chrome/printdialog.properties

deze string is al verwijdert in de trunk en is nog aanwezig in de branch (net
zoals de engelse versie) Maak geen patches waarin strings verwijdert worden,
dit veroorzaakt build problemen!! Als de tinderbox groen is betekend dat alle
strings  goed zijn, als hij oranje wordt kan je in de log zien welke string
teveel of teweinig in de nl versie staat.
Attachment #196413 - Attachment is obsolete: true
Comment on attachment 196438 [details] [diff] [review]
herschikken van bestanden onder mail/messenger/addressbook

toegepast op branch en trunk
Attachment #196438 - Attachment is obsolete: true
Comment on attachment 196508 [details] [diff] [review]
herschikkingen van messengercompose

sorry maar een patch waarin een verandering met een vraagteken staat keur ik
niet goed. Als je ergens over twijfelt, stel het hier dan ter discussie.
Attachment #196508 - Attachment is obsolete: true
Comment on attachment 196439 [details] [diff] [review]
nog meer herschikkingen, maar hier ook met wijzigingen

toegepast op branch en trunk
Attachment #196439 - Attachment is obsolete: true
Comment on attachment 196511 [details] [diff] [review]
herschikkingen van migration

toegepast op branch en trunk
Attachment #196511 - Attachment is obsolete: true
(In reply to comment #93)
> (From update of attachment 196413 [details] [diff] [review] [edit])
> patch toegepast op trunk en branch behalve
> /l10n/l10n/nl/dom/chrome/printdialog.properties
> 
> deze string is al verwijdert in de trunk en is nog aanwezig in de branch (net
> zoals de engelse versie) Maak geen patches waarin strings verwijdert worden,
> dit veroorzaakt build problemen!! Als de tinderbox groen is betekend dat alle
> strings  goed zijn, als hij oranje wordt kan je in de log zien welke string
> teveel of teweinig in de nl versie staat.

Sorry hiervoor, maar ik heb nog steeds niet door hoe je in lxr een andere branch
dan HEAD kan kiezen... iemand?
Ok, sorry voor die vorige, ik heb het gevonden
(In reply to comment #95)
> (From update of attachment 196508 [details] [diff] [review] [edit])
> sorry maar een patch waarin een verandering met een vraagteken staat keur ik
> niet goed. Als je ergens over twijfelt, stel het hier dan ter discussie. 

Ok, dat was geen vraagteken in de zin van `ik weet het niet',  maar gegenereerd
door cvs diff, doordat het een ’ was in een .properties-bestand, en dat werd
blijkbaar niet herkend, daar dit als tekstbestand gedifft wordt (tenminste, zo
kan ik verklaren waarom het in .dtd's wel werkt?).  Ik heb er nu een gewone '
van gemaakt, zou nu in orde moeten zijn.  Verder niks verandert in de patch.
Ik heb net bug 309196 aangemaakt voor de zoekplugins. Bug is in het Engels zodat
QA als nodig makkelijk de discussie kan volgen.
Attached patch Correcties n.a.v. att 193552 (obsolete) — — Splinter Review 

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties n.a.v. att. 193797 (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  

      
      
      
      

        Attached file
          
        xslt.properties (obsolete)
        — 
      

    


  
Kleine correcties. Huidige versie lijkt bovendien in Unix-formaat te zijn (ná
Tortoise dus), vandaar los.

Misschien ook een idee om 'parsen' te gebruiken i.p.v. ontleden?

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties n.a.v. att 194524 (obsolete)
        — 
          — Splinter Review
      

    


  
Zaken genoemd aan einde van comment 31.

    
    

    
  
(In reply to comment #85)
> (In reply to comment #82)
> 
> Thai zit in de laatste patch verstopt, verder kan ik bij e.d. alleen de
> installer-usage bedenken, en dat laat ik voorlopig zo tot we het er eens over
> IRC over gehad hebben, want volgens mij is het nog steeds juist in de derde
persoon.

Dat bedoelde ik niet met e.d., wel eventuele andere zaken die ik misschien
vergat te noemen. Verder vermoed ik dat je comment 31 niet goed hebt gelezen of
begrepen.

(In reply to comment #86)
> (In reply to comment #83)
> > `gewoonlijke' wijzigingen gemaakt.  En het doet me echt pijn om daar `_het_
> > zoekfilter' te laten staan, is `de filter' echt uitgesloten daar in het
> > noorden?
> 
> Yep. :)

Agree.

    
    

    
  
(In reply to comment #102)
> Created an attachment (id=196780) [edit]
> Correcties n.a.v. att 193552
(In reply to comment #103)
> Created an attachment (id=196781) [edit]
> Correcties n.a.v. att. 193797

Op zich ben ik het met al deze zaken eens, maar Thai en de trema's in de
properties zijn in een vorige patch van mij normaal gezien reeds verholpen,
volgens mij werk je dus met een niet geüpdate versie?

    
    

    
  
(In reply to comment #106)
> (In reply to comment #85)
> > (In reply to comment #82)
> Verder vermoed ik dat je comment 31 niet goed hebt gelezen of
> begrepen.

Heel goed gelezen, en ook wel begrepen, maar wat ik me daarbij afvraag: heb je
die opties wel eens uitgeprobeerd of redeneer je vanuit de Engelse tekst?  (Ik
heb ze ook niet uitgeprobeerd hoor).  Ik zie namelijk geen enkele manier om die
MODI te veranderen/beïnvloeden.  Ik begrijp dan ook niet goed of het nu de modi
zijn die gaan of de optie die gaat...  Ik denk dat iemand met kennis van zaken
hier opheldering moet brengen, of dat er anders iemand aan het testen moet gaan.

> (In reply to comment #86)
> > (In reply to comment #83)
> > > `gewoonlijke' wijzigingen gemaakt.  En het doet me echt pijn om daar `_het_
> > > zoekfilter' te laten staan, is `de filter' echt uitgesloten daar in het
> > > noorden?
> > 
> > Yep. :)
> 
> Agree.

Zucht...  Nog kandidaten voor een nl_BE-versie?

    
    

    
  
(In reply to comment #104)
> Misschien ook een idee om 'parsen' te gebruiken i.p.v. ontleden?

Yep. Anders is het inconsistent, zeker wanneer vlak daaronder ook parsefout
wordt gebruikt... Wellicht zou je ‘parseren’ kunnen schrijven, dat laat ik aan
jou over :).


(In reply to comment #108)
> > > > `gewoonlijke' wijzigingen gemaakt.  En het doet me echt pijn om daar
> > > > `_het_ zoekfilter' te laten staan, is `de filter' echt uitgesloten daar
> > > > in het noorden?
> > > 
> > > Yep. :)
> > 
> > Agree.
> 
> Zucht...  Nog kandidaten voor een nl_BE-versie?

:)


~Grauw

    
    

    
  
(In reply to comment #104)
> Created an attachment (id=196782) [edit]
> xslt.properties
> 
> Kleine correcties. Huidige versie lijkt bovendien in Unix-formaat te zijn (ná
> Tortoise dus), vandaar los.
> 
> Misschien ook een idee om 'parsen' te gebruiken i.p.v. ontleden?

ik zie de reden niet waarom je dit bestand los aanbied. Op deze manier kan ik
(makkelijk) niet zien wat je verandert hebt. 

    
    

    
  
(In reply to comment #107)
> (In reply to comment #102)
> 
> Op zich ben ik het met al deze zaken eens, maar Thai en de trema's in de
> properties zijn in een vorige patch van mij normaal gezien reeds verholpen,
> volgens mij werk je dus met een niet geüpdate versie?

Ik update altijd voor het maken van een patch, dus dat zou betekenen dat hij
niet tegen de branch is gemaakt en ik iets anders verkeerd doe. Ik zag echter
nog steeds 'Thais' in charsetTitles.properties, gedateerd 25-08 13:37 (ook na
opnieuw ophalen van branch), welke volgens TM de juiste was. Evenzo kon ik die
correctie niet in enige patch vinden, noch die voor het hier ook nog aanwezige
trema dat wellicht over het hoofd was gezien?

    
    

    
  
(In reply to comment #108)
> 
> Heel goed gelezen, en ook wel begrepen, maar wat ik me daarbij afvraag: heb je
> die opties wel eens uitgeprobeerd of redeneer je vanuit de Engelse tekst?  (Ik
> heb ze ook niet uitgeprobeerd hoor).

Moi non plus, maar dat is ook niet echt nodig als je het mij vraagt; de tekst
moet genoeg zijn. Verder inderdaad geredeneerd vanuit Engels, daarna gekeken of
het ook klopt in het Nederlands (zoals altijd eigenlijk).

> Ik zie namelijk geen enkele manier om die MODI te veranderen/beïnvloeden.

Worden die niet bepaald door de opties -ms en -ma (en het weglaten ervan)?

Immers (huidige vertaling):
-ma: Run setup in Auto mode. / Het installatieprogramma uitvoeren in
automatische modus.
-ms: Run setup in Silent mode. / Het installatieprogramma uitvoeren in stille modus.

Waarin overigens ook een infinitief wordt gebruikt, maar het gaat om door de
gebruiker opgegeven opties.

Als ik me niet vergis wordt de rest van de modi beschouwd als 'normaal'. M.a.w.,
enkel bij het opgeven van -ma of -ms is er sprake van automatisch opruimen,
normaal gesproken wordt hiernaar gevraagd. Vandaar dat je zou kunnen zeggen dat
de modi bepalend zijn, toch?

> Ik begrijp dan ook niet goed of het nu de modi zijn die gaan of de optie die 
> gaat...

En je wist het zo zeker? ;) Ik dacht toch ook dat je op een bepaalde manier
gelijk had.

Maar ehm..,

* NORMAL mode: prompt user on how to proceed / * NORMALE modus: vraagt de
gebruiker hoe door te gaan

Wie of wat vraagt? I.i.g. niet de optie(s), al is het alleen al omdat die
onbekend is/zijn. En de installer is het ook niet eerder geweest in de tekst.
Belangrijker echter: er staat 'prompt', en geen 'prompts', wat eigenlijk al
genoeg zegt. Dit zou zowiezo wijzen op een infinitief, dus 'de gebruiker vragen
hoe..'. En inderdaad, niét op de modi..

* All other modes: assume user wants to cleanup / * Alle andere modi: gaat ervan
uit dat de gebruiker schoon wil maken.

Idem voor de infinitief, dus 'ervan uitgaan dat de..'. Het lijkt erop dat we ons
allebei hebben laten misleiden door het onjuiste 'vraagt' in de normale modus.. :-/

Mijn conclusie: vraagt+gaan kán en misstaat niet, maar is eigenlijk niet juist.
Vraagt+gaat zit er dus nog verder naast en ziet er minder uit. Beide infinitief
maken is misschien het beste, en gewoon het enige écht juiste? :)



    
    

    
  
(In reply to comment #109)
> (In reply to comment #104)
> > Misschien ook een idee om 'parsen' te gebruiken i.p.v. ontleden?
> 
> Yep. Anders is het inconsistent, zeker wanneer vlak daaronder ook parsefout
> wordt gebruikt... Wellicht zou je ‘parseren’ kunnen schrijven, dat laat ik aan
> jou over :).
> 

Ok dan. 'Parseren' klinkt idd ook niet gek maar aangezien 'parsen' in Van Dale
staat en vaker voorkomt (vlg Google) is dat voor nu denk ik het beste.


    
    

    
  

      
      
      
      

        Attached file
          
        xslt.properties (2) (obsolete)
        — 
      

    


  
(In reply to comment #110)
> (In reply to comment #104)
> > Created an attachment (id=196782) [edit] [edit]
> > xslt.properties
> > 
> > Kleine correcties. Huidige versie lijkt bovendien in Unix-formaat te zijn
(ná
> > Tortoise dus), vandaar los.
> 
> ik zie de reden niet waarom je dit bestand los aanbied. Op deze manier kan ik

> (makkelijk) niet zien wat je verandert hebt. 

Zoals erboven aangegeven en via IRC gemeld heeft het bestand hier Unix
linefeeds, na ophalen met Tortoise. Het lijkt er echter op dat dit al zo is
sinds april en wat de reden is weet ik niet, wel dat het een uitzondering is.
Vanwege eerdere problemen hiermee leek apart aanbieden beter, maar als je wilt
kan ik ook wel een patch proberen op de normale manier want het is eerder ook
gelukt in bug 291678, att 185421.

De wijzigingen zijn grammaticale zaken als lidwoorden, werkwoorden en ontleden
-> parsen.

        Attachment #196782 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        xslt.properties (2-2) (obsolete)
        — 
          — Splinter Review
      

    


  
(In reply to comment #114)

> Vanwege eerdere problemen hiermee leek apart aanbieden beter, maar als je
wilt
> kan ik ook wel een patch proberen op de normale manier

Zo kan je kiezen en zijn de wijzigingen duidelijker. ;)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties n.a.v. att 194864 (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties n.a.v. att 195517 (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
(In reply to comment #112)
> (In reply to comment #108)
> > 
> * NORMAL mode: prompt user on how to proceed / * NORMALE modus: vraagt de
> gebruiker hoe door te gaan
> 
> Wie of wat vraagt? I.i.g. niet de optie(s), al is het alleen al omdat die
> onbekend is/zijn. En de installer is het ook niet eerder geweest in de tekst.
> Belangrijker echter: er staat 'prompt', en geen 'prompts', wat eigenlijk al
> genoeg zegt. Dit zou zowiezo wijzen op een infinitief, dus 'de gebruiker vragen
> hoe..'. En inderdaad, niét op de modi..
> 
> * All other modes: assume user wants to cleanup / * Alle andere modi: gaat ervan
> uit dat de gebruiker schoon wil maken.
> 
> Idem voor de infinitief, dus 'ervan uitgaan dat de..'. Het lijkt erop dat we ons
> allebei hebben laten misleiden door het onjuiste 'vraagt' in de normale
modus.. :-/
> 
> Mijn conclusie: vraagt+gaan kán en misstaat niet, maar is eigenlijk niet juist.
> Vraagt+gaat zit er dus nog verder naast en ziet er minder uit. Beide infinitief
> maken is misschien het beste, en gewoon het enige écht juiste? :)

Lijkt me een heel goede conclusie na een degelijke ontleding (parsing?). 
Infinitieven dus.

(In reply to comment #113)
> Ok dan. 'Parseren' klinkt idd ook niet gek maar aangezien 'parsen' in Van Dale
> staat en vaker voorkomt (vlg Google) is dat voor nu denk ik het beste.

Parseren? Brrr...  En zoals reeds gezegd, parsen wordt vziw alleen in een
taalkundige context gebruikt (voor automatische zins*ontleding*).

(In reply to comment #116)
> Created an attachment (id=197163) [edit]
> Correcties n.a.v. att 194864

moet gestart worden om %1$S-koppelingen te verwerken.
moet worden gestart om %1$S:-koppelingen te verwerken.

Ben je zeker dat die : daar hoort?

-  <li>Controleer het adres op typfouten zoals
+  <li>Controleer het adres op typefouten zoals

Het zijn wel degelijk fouten tegen het typen ofte typfouten, en geen fouten
tegen het type, ofte typefouten. (meermaals)

-<!ENTITY redirectLoop.title "De pagina verwijst niet correct door">
+<!ENTITY redirectLoop.title "De pagina verwijst niet goed door">

Bij deze wijziging lijkt me informatie verloren te gaan.  Correct is nog iets
anders dan goed.
(In reply to comment #117)
> Created an attachment (id=197164) [edit]
> Correcties n.a.v. att 195517

<!ENTITY proxiesInfo.label          "Bepalen hoe &brandShortName; verbindt met
het internet.">

Hier zou ik zelfs 'verbinding maakt met' gebruiken.

-<!ENTITY charsetMenu.label "Tekenset">
+<!ENTITY charsetMenu.label "Tekensetcodering">

Ik heb net overal die 'codering' weggehaald, naar voorbeeld van het
menuonderdeeltje in de browser.  Voor consistentie lijkt het me aangewezen dit
zo te houden.  Of te beslissen om er _overal_ tekensetcodering van te maken.

-                          <p>Voor Nederlandse (en andere) spellingcontrole,
bezoek mozdev&#8217;s 
+                          <p>Voor Nederlandse (en andere) spellingcontrole,
bezoek mozdev's 

Ik dacht dat we consequent voor de ´ kozen als afkappingsteken?

<!ENTITY proxiesInfo.label             "Bepalen hoe &brandShortName; verbindt
met het internet.">

Verbinding maakt...

    
    

    
  
(In reply to comment #118)
> Parseren? Brrr...  En zoals reeds gezegd, parsen wordt vziw alleen in een
> taalkundige context gebruikt (voor automatische zins*ontleding*).

Heh, ik vond het wel wat Vlaams aandoen anders :).

Overigens gaat het hier ook om parsen in een taalkundige context.


> Het zijn wel degelijk fouten tegen het typen ofte typfouten, en geen fouten
> tegen het type, ofte typefouten. (meermaals)

Volgens mij kan het allebei (maar houd me daar niet aan), maar we gebruiken
overal elders in Firefox ook typ en geen type.


> -<!ENTITY redirectLoop.title "De pagina verwijst niet correct door">
> +<!ENTITY redirectLoop.title "De pagina verwijst niet goed door">
> 
> Bij deze wijziging lijkt me informatie verloren te gaan.  Correct is nog iets
> anders dan goed.

Zie de meerwaarde van de wijziging ook niet zo.


> <!ENTITY proxiesInfo.label          "Bepalen hoe &brandShortName; verbindt met
> het internet.">
> 
> Hier zou ik zelfs 'verbinding maakt met' gebruiken.

Idd beter.


> -<!ENTITY charsetMenu.label "Tekenset">
> +<!ENTITY charsetMenu.label "Tekensetcodering">
> 
> Ik heb net overal die 'codering' weggehaald, naar voorbeeld van het
> menuonderdeeltje in de browser.  Voor consistentie lijkt het me aangewezen dit
> zo te houden.  Of te beslissen om er _overal_ tekensetcodering van te maken.

Tekenset is correct.

Characterset = tekenset
Character encoding = tekenset

Twee termen voor hetzelfde begrip.


> -                          <p>Voor Nederlandse (en andere) spellingcontrole,
> bezoek mozdev&#8217;s 
> +                          <p>Voor Nederlandse (en andere) spellingcontrole,
> bezoek mozdev's 
> 
> Ik dacht dat we consequent voor de ´ kozen als afkappingsteken?

In Opties/Opstellen/Spelling staat er een link naar:
http://www.mozilla.org/products/thunderbird/dictionaries.html

Lijkt me dat we daarin consistent moeten zijn (en mozilla.org is bovendien
‘officieler’ dan mozdev).


> <!ENTITY proxiesInfo.label             "Bepalen hoe &brandShortName; verbindt
> met het internet.">
> 
> Verbinding maakt...

Mee eens.


~Grauw

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Infinitieven in installer.inc (obsolete)
        — 
          — Splinter Review
      

    


  
(In reply to comment #118)
> 
> Lijkt me een heel goede conclusie na een degelijke ontleding (parsing?). 
> Infinitieven dus.

Patch is wat groot door de lange regel maar de enige wijzigingen zijn

vraagt de gebruiker -> de gebruiker vragen
gaat ervan uit dat -> ervan uitgaan dat

    
    

    
  
(In reply to comment #118)
> 
> Parseren? Brrr...  En zoals reeds gezegd, parsen wordt vziw alleen in een
> taalkundige context gebruikt (voor automatische zins*ontleding*).

Van Dale kent slechts 1 uitleg:
1 [comp.] het automatisch syntactisch analyseren

Tja.. Of het nu taalkundig of computertechnisch gebeurt, de ontleding is toch
min of meer dezelfde?

> moet gestart worden om %1$S-koppelingen te verwerken.
> moet worden gestart om %1$S:-koppelingen te verwerken.
> 
> Ben je zeker dat die : daar hoort?

Lijkt me van wel; hij staat ook in de oorspronkelijke tekst en is volgens mij
niets anders dan de : die voorkomt na ieder protocol, als bij http:, news: etc.,
dus de scheiding tussen type en adres.
 
> Het zijn wel degelijk fouten tegen het typen ofte typfouten, en geen fouten
> tegen het type, ofte typefouten. (meermaals)

Volgens de regels zou het toch echt 'typefouten' moeten zijn. Ik begrijp je
redenatie wel en zou ook niet zo goed weten hoe je dan een fout van een bepaald
type formuleert, maar het is niet anders. Zie Van Dale, Wiki, GB, met Google te
vinden resultaten van discussies etc. en zelfs het Mozbrowser-forum (art 28649).
Heeft overigens niets te maken met gebruik van typ of typen i.h.a., komt slechts
eenmaal voor en is ook in juni gewijzigd naar +e, toen in dom/chrome/neterror.dtd.

> -<!ENTITY redirectLoop.title "De pagina verwijst niet correct door">
> +<!ENTITY redirectLoop.title "De pagina verwijst niet goed door">
> 
> Bij deze wijziging lijkt me informatie verloren te gaan.  Correct is nog iets
> anders dan goed.

Ik wilde aanvankelijk 'juist' gebruiken (net als op veel andere plaatsen in de
teksten i.p.v. 'correct'), gevolgd door 'op een juiste manier', en heb er
vanwege de lengte maar 'goed' van gemaakt. 'Op een juiste manier' lijkt me in
deze string toch het beste dus ik maak dat er wel van. De reden: 'correct' wordt
in het Nederlands nauwelijks als bijwoord gebruikt, en ook niet echt vaak als
bijvoeglijk naamwoord, dus 'op een correcte manier' verdient ook geen voorkeur.
Maar misschien het belangrijkste: 'properly' in de Engelse tekst is iets anders
dan 'correctly'..

> <!ENTITY proxiesInfo.label          "Bepalen hoe &brandShortName; verbindt met
> het internet.">
> 
> Hier zou ik zelfs 'verbinding maakt met' gebruiken.

Vooruit dan. Op zich vind ik dat er weinig mis is met 'verbindt' maar het andere
staat idd beter.

> -<!ENTITY charsetMenu.label "Tekenset">
> +<!ENTITY charsetMenu.label "Tekensetcodering">
> 
> Ik heb net overal die 'codering' weggehaald, naar voorbeeld van het
> menuonderdeeltje in de browser.  Voor consistentie lijkt het me aangewezen dit
> zo te houden.  Of te beslissen om er _overal_ tekensetcodering van te maken.

Eindelijk, de langverwachte discussie. :)

Ik weet niet waar je het overal hebt weggehaald (lokaal?), maar in de huidige
cvs is sinds mei al sprake van verandering naar 'tekensetcodering', ook in het
menuonderdeel. Uiteraard moet de boel consistent zijn en dat was ook mijn
bedoeling; het bestand in kwestie (charset.dtd) is ook het enige bestand waarin
dit nog niet was gefixt omdat ik het eerder niet had meegenomen, vermoedelijk
vanwege de aanname dat het niet meer werd gebruikt.

Overigens een vriendelijk verzoek om als het even kan, en i.i.g. zodra je het
geringste vermoeden hebt dat een term al eerder is gewijzigd, dit na te lopen in
de historie van een bestand. Het is dan denk ik handiger om zo'n geval
bespreekbaar te maken i.p.v. opnieuw te wijzigen (is eerder gebeurd dacht ik).
En oja, iets minder quoten als het kan. ;)

Wat betreft de vertaling: tenzij ik me vergis is er wel degelijk verschil tussen
'character encoding' en 'character set'. Ook al stuit men bij de uitleg over
deze begrippen helaas vaak op 'gesmokkel': de gebruikte (en in het document
vastgelegde) tekenset en de door een browser gehanteerde (de)codering zijn wel
degelijk verschillende dingen, wat de mensen bij Netscape, MS (IE) en KDE wel
goed lijken te hebben begrepen. Áls er al sprake is van een geoorloofde
inkorting van het begrip tekensetcodering of karaktercodering dan zal men eerder
uitkomen op 'codering', evenals in IE. Het is echter net alsof hier iemand een
enorme hekel heeft aan het woord 'encoding' en/of 'codering' (al dan niet
vanwege de verwarring met 'encryptie' en/of 'code schrijven'), wat zelfs zo ver
lijkt te gaan dat dit woord in zijn eentje al wordt vervangen door 'tekenset'
(!), zoals in de entiteit generalEncoding in pageinfo.dtd. Ook daar is immers
sprake van een gedetecteerde of zelf ingestelde -en dus gehanteerde- codering en
een vertaling met 'tekenset' is naar mijn idee simpelweg misleidend, of op zijn
minst gesmokkel, evenals in de andere gevallen.

Totdat iemand, en ik vermoed dat dat Laurens zal zijn, mij (e.a.) ervan kan
overtuigen dat het bovenstaande niet waar is en er een 100% sluitende en
rechtvaardigende uitleg komt voor het begrip 'character encoding' of het
gesmokkel daaromtrent lijkt het me daarom het beste om deze wijziging in dit
waarschijnlijk niet eens meer gebruikte bestand gewoon door te voeren en daarmee
i.i.g. consistentie te leveren in de hele tekst, en niet bij te dragen aan de
reeds bestaande verwarring. Ook handiger voor IE-gebruikers, maar dat is niet
eens de belangrijkste reden. ;)

> -                          <p>Voor Nederlandse (en andere) spellingcontrole,
> bezoek mozdev&#8217;s 
> +                          <p>Voor Nederlandse (en andere) spellingcontrole,
> bezoek mozdev's 
> 
> Ik dacht dat we consequent voor de ´ kozen als afkappingsteken?

Het ging hier hoofdzakelijk om het verwijderen van de in HTML gehanteerde
&#8217-code i.p.v. de €™, welke in het verleden al vaker tot problemen heeft
geleid. Verder wordt de ´ vooralsnog alleen in FF gebruikt, vandaar een normale '.


    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties n.a.v. att 194864 (2) (obsolete)
        — 
          — Splinter Review
      

    


  
goed -> op een juiste manier

        Attachment #197163 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties n.a.v. att 195517 (2) (obsolete)
        — 
          — Splinter Review
      

    


  
verbindt -> verbinding maakt (x2)

        Attachment #197164 -
        Attachment is obsolete: true

    
    

    
  
Het verschil tussen character encoding en character set is dat Unicode een
character set is, en UTF-8 en UTF-8 verschillende character encodings van
Unicode. Set betekent "de set van tekens (inclusief codepunten van deze)", en
encoding betekent "een representatie van de tekens".

Dit heeft dus niets met een verschil tussen en- en decodering te maken.

In de praktijk zit er nauwelijks onderscheid tussen. Het verschil zoals
hierboven beschreven is niet van toepassing op de meeste tekensets anders dan
Unicode (Latin-1, SJIS, etc). Daarom is er uit historisch oogpunt nooit echt een
dergelijk onderscheid tussen gemaakt.

Het belangrijkste verschil in het Engels is dat character set een wat
ouderwetsere term is dan character encoding. De reden dat het laatste
tegenwoordig wordt gebruikt is omdat het iets correcter is om over character
encoding te spreken bij een lijst waarin zowel UTF-8 als UTF-16 voorkomen.

Voorbeelden:
- Het oude HTTP protocol gebruikt
  Content-Type: text/html; charset=UTF-8
- Het nieuwere XML gebruikt
  <?xml version="1.0" encoding="UTF-8"?>

Nu wat de Nederlandse vertaling betreft:

In het Nederlands tekensetcodering schrijven ben ik volledig op tegen. Ten
eerste omdat tekenset een bestaande term is, en tekensetcodering een verzinsel.
Het is een lelijk en lang pleonasme, dat als je het terug vertaalt "character
set encoding" betekent.

Tekensetcodering schrijven is een typisch voorbeeld van een rigide
te-rechtstreekse vertaling uit het Engels, in het streven naar een correctheid
die er niet is. Het maakt het alleen slechter leesbaar.

Conclusie: de term ‘character set’ is in het Engels vervangen door ‘character
encoding’. In het Nederlands is dit niet gebeurd, en wij moeten ons ook niet toe
geroepen voelen om daar improvisorisch verandering in te brengen.

Overtuigd? :)


~Grauw

    
    

    
  
Correctie: UTF-8 en UTF-16.

    
    

    
  


  
Deze patch verbert nog wat puntjes die de locale-inspector doorgaf en die
ondertussen nog niet verbetert waren. Daarnaast enkele correcties naar de
infinitief die ik een keer tegenkwam.

    
    

    
  
(In reply to comment #121)
> En oja, iets minder quoten als het kan. ;)

Hoe bedoel je?
 
> > -                          <p>Voor Nederlandse (en andere) spellingcontrole,
> > bezoek mozdev&#8217;s 
> > +                          <p>Voor Nederlandse (en andere) spellingcontrole,
> > bezoek mozdev's 
> > 
> > Ik dacht dat we consequent voor de ´ kozen als afkappingsteken?
> 
> Het ging hier hoofdzakelijk om het verwijderen van de in HTML gehanteerde
> &#8217-code i.p.v. de €™, welke in het verleden al vaker tot problemen heeft
> geleid. Verder wordt de ´ vooralsnog alleen in FF gebruikt, vandaar een normale '.

Is het niet wat onnozel om daar een verschil in te maken?  We zijn toch één
vertaalteam (al was dat vroeger misschien anders)?

    
    

    
  
(In reply to comment #91)
> (From update of attachment 196414 [details] [diff] [review] [edit])
> patch is niet toegepast. Een venster vergroten zonder zelf het eerst te testen
> met een schone installatie is niet de goed methode (een venster die je met de
> muis groter of kleiner maakt wordt opgeslagen in de instellingen)
> 
> brandShortName is wel verandert.

Ik heb nu eens een nieuw profiel aangemaakt, daarin niks veranderd, een nieuwe
nightly geïnstalleerd, en dan de themabeheerder geopend, en die vertoont bij het
openen een schuifbalk in het linkse deel.  Dat kan toch niet de bedoeling zijn?
 En de koppeling `meer thema’s verkrijgen’ valt gedeeltelijk buiten het venster.
 Gelieve deze patch dus alsnog toe te passen, of toch zeker de wijzigingen van
de themabeheerder, maar ook voor de extensiebeheerder kan het m.i. geen kwaad.

    
    

    
  


  
Dit is een hele reeks van wijzigingen die ik gemaakt heb, die niet met het
herschikken van bestanden te maken hebben.

Belangrijkste zijn: 
offline-gebruik -> offlinegebruik
tekenset* -> tekenset
overal.

Verder enkele foute vertalingen en schoonheidsfoutjes. (Hoop dat de patch nog
werkt, heb erin zitten knippen)

    
    

    
  
(In reply to comment #128)
> Ik heb nu eens een nieuw profiel aangemaakt, daarin niks veranderd, een nieuwe
> nightly geïnstalleerd, en dan de themabeheerder geopend, en die vertoont bij het
> openen een schuifbalk in het linkse deel.  Dat kan toch niet de bedoeling zijn?
>  En de koppeling `meer thema’s verkrijgen’ valt gedeeltelijk buiten het venster.
>  Gelieve deze patch dus alsnog toe te passen, of toch zeker de wijzigingen van
> de themabeheerder, maar ook voor de extensiebeheerder kan het m.i. geen kwaad.
In een nieuw profiel heb ik hier helemaal geen last van. Op welk
besturingssysteem zie je dit trouwens en gebruik je een normale lettergrootte.
Misschien kun je een schermafbeelding ervan maken. Dan kunnen wij misschien zien
wat het probleem is.

Wat Tim Maks volgensmij bedoelde met zijn opmerking over het vergroten van
vensters is dat je nadat je de wijzigingen hebt doorgevoerd lokaal, je in een
nieuw profiel moet testen of het venster dan wel goed is (of misschien weer net
iets te groot) en niet direct een patch moet plaatsen.

    
    

    
  
(In reply to comment #124)
> Het verschil tussen character encoding en character set is dat Unicode een
> character set is, en UTF-8 en UTF-16 verschillende character encodings van
> Unicode. Set betekent "de set van tekens (inclusief codepunten van deze)", en
> encoding betekent "een representatie van de tekens".

Ik weet niet of ik het helemaal eens kan zijn met de eerste zin (of ik begrijp
het niet :) ), maar dit even terzijde. Met het aangegeven verschil tussen set en
encoding wel, en dat is ook mijn punt; gaat het immers niet om het aanpassen van
de codering, en niet om de set, ook al zou ermee 'ongeveer' hetzelfde worden
bedoeld?

> Dit heeft dus niets met een verschil tussen en- en decodering te maken.

Inderdaad, ik doelde ook op de representatie / weergave. Of begrijp ik je nu
verkeerd?

> In de praktijk zit er nauwelijks onderscheid tussen. Het verschil zoals
> hierboven beschreven is niet van toepassing op de meeste tekensets anders dan
> Unicode (Latin-1, SJIS, etc). Daarom is er uit historisch oogpunt nooit echt een
> dergelijk onderscheid tussen gemaakt.

Is het dan niet handig om alleen al vanwege het tegenwoordig vaker gebruikte
UTF-16 wel een onderscheid te maken?

> Het belangrijkste verschil in het Engels is dat character set een wat
> ouderwetsere term is dan character encoding. De reden dat het laatste
> tegenwoordig wordt gebruikt is omdat het iets correcter is om over character
> encoding te spreken bij een lijst waarin zowel UTF-8 als UTF-16 voorkomen.

Idem (^). M.a.w., is het niet correcter om tegenwoordig over karakter- of
tekencodering te spreken?

> Voorbeelden:
> - Het oude HTTP protocol gebruikt
>   Content-Type: text/html; charset=UTF-8
> - Het nieuwere XML gebruikt
>   <?xml version="1.0" encoding="UTF-8"?>

Dit snijdt hout, v.w.b. het 'hetzelfde zijn'. Blijft zaak dat het om encoding
gaat, niet om een set.

> In het Nederlands tekensetcodering schrijven ben ik volledig op tegen. Ten
> eerste omdat tekenset een bestaande term is, en tekensetcodering een verzinsel.
> Het is een lelijk en lang pleonasme, dat als je het terug vertaalt "character
> set encoding" betekent.

Helemaal mee eens, maar dan alleen vanwege het 'set'. Het zou dan ook
'tekencodering' moeten zijn, vandaar dat ik karaktercodering ook noemde. Ik zou
die term waarschijnlijk zelf hebben gebruikt bij een eerste vertaling. (De vraag
of het hierin 'karakter' of 'teken' zou moeten zijn is me bekend en laat ik hier
even in het midden.)

> Tekensetcodering schrijven is een typisch voorbeeld van een rigide
> te-rechtstreekse vertaling uit het Engels, in het streven naar een correctheid
> die er niet is. Het maakt het alleen slechter leesbaar.

Vind je dat ook van 'tekencodering'?

> Conclusie: de term ‘character set’ is in het Engels vervangen door ‘character
> encoding’. In het Nederlands is dit niet gebeurd, en wij moeten ons ook niet toe
> geroepen voelen om daar improvisorisch verandering in te brengen.

OK v.w.b. het Engels, maar dan wederom: wat is er mis met 'tekencodering'? Deze
term staat dichter bij het origineel en wordt evenals 'karaktercodering' ook
vaak gebruikt (I hate to say this, maar ook door MS in bijv. haar XML-uitleg, en
de laatste door overheid.nl, zie Google). Termen als 'de codering van de
tekenset' komen ook vaak voor, en wat te zeggen van bijvoorbeeld de pagina over
'karaktercodering' van Anne?
 
> Overtuigd? :)

Helaas, maar nog niet helemaal. :) Begrijp me niet verkeerd, ik stem er volledig
mee in als je gelijk hebt maar ik heb nog steeds sterke twijfels vanwege het
verschil tussen set en codering. FF lijkt op dit moment wel het enige geval te
zijn waarin hierin wordt afgeweken en dit kan gewoon leiden tot verwarring bij
veel gebruikers, waaronder ikzelf blijkbaar. :)

Wat is overigens de mening van anderen over deze termen?

    
    

    
  
(In reply to comment #131)
> Ik weet niet of ik het helemaal eens kan zijn met de eerste zin (of ik begrijp
> het niet :) ), maar dit even terzijde.

Het is niet echt een kwestie van ‘het ermee eens zijn’...


> Met het aangegeven verschil tussen set en
> encoding wel, en dat is ook mijn punt; gaat het immers niet om het aanpassen
> van de codering, en niet om de set, ook al zou ermee 'ongeveer' hetzelfde
> worden bedoeld?

Aanpassen van de codering en de set is hetzelfde. Als ik Latin-1 instel, dan
verander ik zowel de codering als de set. Als ik UTF-8 instel, ditto. Als ik van
UTF-8 naar een UTF-16 encodering zou gaan, dan verander ik alleen de codering en
niet de set, die is nog steeds Unicode, maar dat is een vrij onbelangrijk detail.

Ik heb erover geblogd, op http://www.grauw.nl/blog/?entry=254 , misschien maakt
dat het nog iets duidelijker.


> > Dit heeft dus niets met een verschil tussen en- en decodering te maken.
> 
> Inderdaad, ik doelde ook op de representatie / weergave. Of begrijp ik je nu
> verkeerd?

Ja.


> > In de praktijk zit er nauwelijks onderscheid tussen. Het verschil zoals
> > hierboven beschreven is niet van toepassing op de meeste tekensets anders
> > dan Unicode (Latin-1, SJIS, etc). Daarom is er uit historisch oogpunt nooit
> > echt een dergelijk onderscheid tussen gemaakt.
> 
> Is het dan niet handig om alleen al vanwege het tegenwoordig vaker gebruikte
> UTF-16 wel een onderscheid te maken?

UTF-16 wordt niet vaker gebruikt. Met uitzondering van internet
OS-representaties is UTF-16 zelden gebruikt. En al helemaal niet op het web.


> > Het belangrijkste verschil in het Engels is dat character set een wat
> > ouderwetsere term is dan character encoding. De reden dat het laatste
> > tegenwoordig wordt gebruikt is omdat het iets correcter is om over character
> > encoding te spreken bij een lijst waarin zowel UTF-8 als UTF-16 voorkomen.
> 
> Idem (^). M.a.w., is het niet correcter om tegenwoordig over karakter- of
> tekencodering te spreken?

Zoals ik al zei, dan bedenk je een nieuwe, eigen term voor iets waar al een
prima Nederlandse vertaling voor bestaat.

In het Engels is dit zo ‘gegroeid’. In het Nederlands niet. Het Engels achterna
gaan is dus gewoon incorrect vertalen.


> > Tekensetcodering schrijven is een typisch voorbeeld van een rigide
> > te-rechtstreekse vertaling uit het Engels, in het streven naar een
> > correctheid die er niet is. Het maakt het alleen slechter leesbaar.
> 
> Vind je dat ook van 'tekencodering'?

Ja.


> OK v.w.b. het Engels, maar dan wederom: wat is er mis met 'tekencodering'?
> Deze term staat dichter bij het origineel en wordt evenals 'karaktercodering'
> ook vaak gebruikt (I hate to say this, maar ook door MS in bijv. haar
> XML-uitleg, en de laatste door overheid.nl, zie Google). Termen als 'de
> codering van de tekenset' komen ook vaak voor, en wat te zeggen van
> bijvoorbeeld de pagina over 'karaktercodering' van Anne?

Ik vind het allemaal misbaksels :). Tekenset is goed genoeg.

Je loopt nu je in bochten te wringen om een nieuwe vertaling te bedenken, omdat
je niet kunt accepteren dat tekenset het Nederlandse woord is voor tekenset.


> mee in als je gelijk hebt maar ik heb nog steeds sterke twijfels vanwege het
> verschil tussen set en codering.

Dit verschil is er niet.


~Grauw

    
    

    
  
Als ik even olie op het vuur mag gooien: ik vind `set' in de betekenis van
`verzameling' op zch al een lelijke vertaling.  (Maar vind ook wel dat we geen
verschil tussen beide moeten maken)

    
    

    
  
(In reply to comment #127)
> (In reply to comment #121)
> > En oja, iets minder quoten als het kan. ;)
> 
> Hoe bedoel je?

Wat dacht je van enkel quoten van terzake doende vragen en/of uitspraken? Je had
in comment #118 vanaf 'Mijn conclusie' kunnen quoten i.p.v. vanaf "* NORMAL
mode:".. :)

> > geleid. Verder wordt de ´ vooralsnog alleen in FF gebruikt, vandaar een
normale '.
> 
> Is het niet wat onnozel om daar een verschil in te maken?  We zijn toch één
> vertaalteam (al was dat vroeger misschien anders)?

Wat heeft dat met het team te maken? Of doel je op het verschil in apostrof
tussen FF en TB? In dat geval: Anne wilde een tijdje geleden graag de schuine
apostrof, of liever gezegd een curly apostrof introduceren in FF en dat is ook
gebeurd. Inderdaad doet dat verschil sinds het samengaan van TB en FF in de bug
misschien wat vreemd aan, maar er was gewoon nog niemand die heeft voorgesteld
om dit ook in TB zo te doen. Daarbij, maar misschien ben ik de enige die dat
belangrijk vindt, leek het mij handig om hem pas op het laatst in te voeren, al
dan niet door een script (zo deed Anne dat dacht ik ook), om het editen
makkelijker te maken aangezien de curly afhankelijk is van
toetsenbordinstelling/taal etc. en dus de meesten waarschijnlijk standaard een
rechte typen, althans zonder Word o.i.d.

Nu we het er toch over hebben: ik denk de curly apostrof lang niet in alle
gevallen een mooiere apostrof oplevert. Daar waar deze idd curly is (dus
'krullend'), zoals in HTML-pagina's heb ik allerminst bezwaar tegen het gebruik
ervan maar in veel gevallen, zoals in menu's, is hij schuin en vaak identiek aan
het acute accent, met als bijkomstigheid dat hij net zo breed is als een letter,
zoals in 'meer thema´s verkrijgen' in de extensiebeheerder, wat waarschijnlijk
wordt veroorzaakt door een vaste-breedte-lettertype. Vandaar dit: is het
misschien een idee om alleen curly quotes te gebruiken daar waar ze dat ook
worden? Let wel, het betreft dan de apostrofs, niet de rechtse aanhalingstekens,
die vermoedelijk om dezelfde reden ook niet altijd curly zijn maar waarbij dit
minder opvalt.

Ik zag ook dat je (Hendrik) sinds kort \u2019 (rechts aanhalingsteken) gebruikt
voor apostrofs i.p.v. \u00B4 (acute accent). Dit zou wel beter zijn (als dit
maar overal gebeurt) maar ik vraag me wel af of dit geen problemen oplevert
aangezien hij buiten de (als ik me niet vergis) ASCII-tekenset valt, wat wel
eens de reden zou kunnen zijn dat er tot nu toe is gekozen voor \u00B4, ofwel
het acute accent. Misschien dat dit ook de reden is dat een curly in het geval
van de apostrof ook niet goed wordt weergegeven.. Kan iemand hier uitsluitsel
over geven?


    
    

    
  
(In reply to comment #134)
> (In reply to comment #127)
> > (In reply to comment #121)
> > > geleid. Verder wordt de ´ vooralsnog alleen in FF gebruikt, vandaar een
> normale '.
> > 
> > Is het niet wat onnozel om daar een verschil in te maken?  We zijn toch ייn
> > vertaalteam (al was dat vroeger misschien anders)?
> 
> Wat heeft dat met het team te maken? Of doel je op het verschil in apostrof
> tussen FF en TB? 

Ja.
Lijkt me een goed idee om dit een keer met een script te doen, dat lost ook de
problemen met .properties-bestanden op, waar ze taboe is.  Maar w.m.b. liefst
overal hetzelfde (ik ben nog niet lang genoeg bij de vertalers om het
samenvoegen meegemaakt te hebben, vandaar mijn onwetendheid)

> Ik zag ook dat je (Hendrik) sinds kort \u2019 (rechts aanhalingsteken) gebruikt
> voor apostrofs i.p.v. \u00B4 (acute accent). 

Ik weet niet goed wat je bedoelt: met het toetsenbord kan ik die rechtstreeks
ingeven (Alt rechts + 0, tenminste, op mijn windows-pc), en de code \u2019 heb
ik eens overgekopieerd, niet zelf bedacht.


    
    

    
  
Correctie: "Met uitzondering van *interne* OS-representaties"


(In reply to comment #134)
> Anne wilde een tijdje geleden graag de schuine
> apostrof, of liever gezegd een curly apostrof introduceren in FF en dat is ook
> gebeurd.

Niet alleen Anne, ik ook.


> maar in veel gevallen, zoals in menu's, is hij schuin en vaak identiek aan
> het acute accent, met als bijkomstigheid dat hij net zo breed is als een
> letter, zoals in 'meer thema´s verkrijgen' in de extensiebeheerder

Als het accent net zo breed is als een letter, dan is er de verkeerde gebruikt,
namelijk een accent acute (´) ipv. een right curling quote (’). Dat zijn twee
afzonderlijke tekens. We moeten de laatste gebruiken, de eerste is fout.

M.b.t. invoer van dit teken, als je Windows gebruikt zit dit in de International
keyboard layout onder ALTGR+9 en ALTGR+0. Als je normaal gesproken een andere
layout gebruikt zou dat geen probleem moeten zijn want in Windows kan je daar
heel makkelijk tussen schakelen. In de andere gevallen zijn deze tekens
eenvoudig in de character map te vinden, kies daarvoor ‘advanced view’, ‘group
by: unicode subrange’, ‘general punctuation’, en daar staat hij dan tussen.


~Grauw

    
    

    
  
(In reply to comment #135)
> > Ik zag ook dat je (Hendrik) sinds kort \u2019 (rechts aanhalingsteken) gebruikt
> > voor apostrofs i.p.v. \u00B4 (acute accent). 
> 
> Ik weet niet goed wat je bedoelt: met het toetsenbord kan ik die rechtstreeks
> ingeven (Alt rechts + 0, tenminste, op mijn windows-pc), en de code \u2019 heb
> ik eens overgekopieerd, niet zelf bedacht.

Hendrik doet het hier correct. Als je iets anders deed (\u00B4 dus), dan was dat
fout, en dat moet gecorrigeerd worden.


~Grauw

    
    

    
  
(In reply to comment #132)
> 
> Het is niet echt een kwestie van ‘het ermee eens zijn’...

Nou ja zeg..

> Aanpassen van de codering en de set is hetzelfde. Als ik Latin-1 instel, dan
> verander ik zowel de codering als de set. Als ik UTF-8 instel, ditto. Als ik van
> UTF-8 naar een UTF-16 encodering zou gaan, dan verander ik alleen de codering en
> niet de set, die is nog steeds Unicode, maar dat is een vrij onbelangrijk detail.

Ik vermoed dat het nou net om dit detail gaat, aangezien je zelf aangeeft dat
het de codering is die wordt veranderd.

> Ik heb erover geblogd, op http://www.grauw.nl/blog/?entry=254 , misschien maakt
> dat het nog iets duidelijker.

Ik hoopte het, maar het lijkt alleen een log te zijn van wat je eerder schreef.. :-/

> > M.a.w., is het niet correcter om tegenwoordig over karakter- of
> > tekencodering te spreken?
> 
> Zoals ik al zei, dan bedenk je een nieuwe, eigen term voor iets waar al een
> prima Nederlandse vertaling voor bestaat.

Karaktercodering lijkt me nog steeds een prima vertaling van character encoding,
afgezien van karakter. Alleen tekensetcodering lijkt me inderdaad zelf bedacht.
Maar blijkbaar is dat een verkeerde redenatie.

> In het Engels is dit zo ‘gegroeid’. In het Nederlands niet. Het Engels achterna
> gaan is dus gewoon incorrect vertalen.

..

> > Vind je dat ook van 'tekencodering'?
> 
> Ja.

Omdat? Dit vind ik nou net de belangrijkste vraag. :)

> Ik vind het allemaal misbaksels :). Tekenset is goed genoeg.

Is helaas geen antwoord op de vraag. Waarom gebruiken professionele vertalers
bij bijv. MS tekencodering, en de overheid (en Anne) karaktercodering? Ben ook
benieuwd naar Anne's antwoord trouwens.

> Je loopt nu je in bochten te wringen om een nieuwe vertaling te bedenken, omdat
> je niet kunt accepteren dat tekenset het Nederlandse woord is voor tekenset.

Wil je a.j.b. wat voorzichtiger zijn met een dergelijke beschuldiging? Ik dacht
duidelijk te hebben aangegeven dat ik je graag gelijk geef zodra ik ben
overtuigd. Dat is wat anders dan iets niet accepteren, zelfs al is het waar; die
fase ben ik allang voorbij. :)

Maar voordat je reageert: ik leg me er wel bij neer, al ben ik nog steeds
benieuwd naar andere meningen.


    
    

    
  
Karaktercodering werd al het meest gebruikt volgens Google.
 <http://www.google.nl/search?q=karaktercodering>
 <http://www.google.nl/search?q=tekensetcodering>
 <http://www.google.nl/search?q=tekencodering>

Het is tevens de meest duidelijke "mapping" met 'character encoding':
 <http://www.google.nl/search?q=character+encoding>

    
    

    
  
(In reply to comment #136)

> Als het accent net zo breed is als een letter, dan is er de verkeerde gebruikt,
> namelijk een accent acute (´) ipv. een right curling quote (’). Dat zijn twee
> afzonderlijke tekens. We moeten de laatste gebruiken, de eerste is fout.

Daar doelde ik ook op (en dus mee eens); ik heb het alleen nog niet getest met
2019 op die plaats. Hoewel.. in het verleden misschien wel en ik meen me te
herinneren dat dat een even zo breed karakter opleverde, maar kan me nu
vergissen. Fixed font blijft immers fixed font... :(

> M.b.t. invoer van dit teken, als je Windows gebruikt zit dit in de
International...

Thanks.

(In reply to comment #137)
> 
> Hendrik doet het hier correct. Als je iets anders deed (\u00B4 dus), dan was dat
> fout, en dat moet gecorrigeerd worden.

Is idd de bedoeling, maar ik maak me alleen zorgen over of het goed gaat werken
en geen rare tekens oplevert. Zie overigens ook het onderwerp 'Verbeteringen
nieuwe Firefox-vertaling' bij Mozbrowser, rond pag. 21 e.v.


    
    

    
  


  
En 1 string.

    
    

    
  
(In reply to comment #138)
> > Het is niet echt een kwestie van ‘het ermee eens zijn’...
> 
> Nou ja zeg..

Ik bedoel, hoe we het in het Nederlands vertalen staat ter discussie, maar het
verschil in het Engels is zoals ik het uitleg :).


> Ik vermoed dat het nou net om dit detail gaat, aangezien je zelf aangeeft dat
> het de codering is die wordt veranderd.

De set wordt ook veranderd.

Wat ik duidelijk probeer te maken is dat 1. in het Engels er historisch gezien
zelden onderscheid tussen wordt gemaakt, en belangrijker dat 2. er in het
Nederlands historisch gezien zo goed als nooit onderscheid tussen wordt gemaakt.


> > Ik heb erover geblogd, op http://www.grauw.nl/blog/?entry=254 , misschien maakt
> > dat het nog iets duidelijker.
> 
> Ik hoopte het, maar het lijkt alleen een log te zijn van wat je eerder
schreef.. :-/

Oh, nouja, er stond nog een voorbeeld bij. Het heeft in ieder geval niks met een
verschil tussen bron en browser te maken.


> Karaktercodering lijkt me nog steeds een prima vertaling van character encoding,
> afgezien van karakter. Alleen tekensetcodering lijkt me inderdaad zelf bedacht.
> Maar blijkbaar is dat een verkeerde redenatie.

Het gaat om het feit dat je zelf termen gaat bedenken omdat je blijkbaar een
perfecte mapping met de Engelse terminologie wilt. Zelf termen bedenken is niet
goed, als het vermeden kan worden.


> > > Vind je dat ook van 'tekencodering'?
> > 
> > Ja.
> 
> Omdat? Dit vind ik nou net de belangrijkste vraag. :)

Omdat je het ter plekke bedenkt.


> > Ik vind het allemaal misbaksels :). Tekenset is goed genoeg.
> 
> Is helaas geen antwoord op de vraag. Waarom gebruiken professionele vertalers
> bij bijv. MS tekencodering, en de overheid (en Anne) karaktercodering? Ben ook
> benieuwd naar Anne's antwoord trouwens.

Ook Microsoft kan het fout doen. Character encoding als karaktercodering
vertalen ligt op het eerste gezicht het meest voor de hand, dus ik kan een
dergelijke vertaling wel begrijpen, maar ik ben het er niet mee eens.

Overigens gebruikt Microsoft in IE ‘codering’, dus dat geeft ook maar weer eens
aan dat zij daar geen consistentie in hebben.


(In reply to comment #140)
> Is idd de bedoeling, maar ik maak me alleen zorgen over of het goed gaat werken
> en geen rare tekens oplevert. Zie overigens ook het onderwerp 'Verbeteringen
> nieuwe Firefox-vertaling' bij Mozbrowser, rond pag. 21 e.v.

We doen dit al sinds Firefox 1.0 en hebben er nog geen één klacht over gehad.
Alle fonts hebben deze ‘ ’ tekens ook gewoon, vziw. Als ik een probleem met
spacing zag lag dat altijd aan het gebruik van een accent ipv een aanhalingsteken.


(In reply to comment #139)
> Karaktercodering werd al het meest gebruikt volgens Google.
>  <http://www.google.nl/search?q=karaktercodering>
>  <http://www.google.nl/search?q=tekensetcodering>
>  <http://www.google.nl/search?q=tekencodering>

http://www.google.nl/search?q=tekenset

Overigens geeft het feit dat tekensetcodering ook 70 resultaten geeft maar weer
aan dat als er iets fout gedaan kan worden, dat dat ook gebeurt :).

Maar goed:

tekensetcodering - 70 resultaten
tekencodering    - 225 resultaten
karaktercodering - 238 resultaten
tekenset         - 17400 resultaten

Dan maak je mij toch niet wijs dat tekenset niet de juiste vertaling is.


> Het is tevens de meest duidelijke "mapping" met 'character encoding':
>  <http://www.google.nl/search?q=character+encoding>

Bij vertalen werk je niet met 1 op 1 mappings.


~Grauw

    
    

    
  


  
(In reply to comment #130)
> Misschien kun je een schermafbeelding ervan maken. Dan kunnen wij misschien
zien
> wat het probleem is.

Bij deze. Dat is op WinXP.
 
> Wat Tim Maks volgensmij bedoelde met zijn opmerking over het vergroten van
> vensters is dat je nadat je de wijzigingen hebt doorgevoerd lokaal, je in een

> nieuw profiel moet testen of het venster dan wel goed is (of misschien weer
net
> iets te groot) en niet direct een patch moet plaatsen.

Hoe zie je dit?  Ik ben nog niet zo ver gevorderd dat ik zelf ook builds maak,
maar wil dat misschien wel eens proberen.  Alles wat hier met de vertalingen te
maken heeft doe ik op deze comp met WinXP, heb echter ook toegang tot Linux als
dat makkelijker is.

    
    

    
  
(In reply to comment #143)

De extensiebeheerder ziet er hier overigens goed uit.

    
    

    
  
Het is overigens helemaal geen optie om in TB de apostrof niet te vervangen,
daar er een stuk gedeelde code is waar die in voorkomt, zie bijvoorbeeld het
koppelingetje `meer thema’s verkrijgen’ in de themabeheerder, die in toolkit zit...

    
    

    
  
(In reply to comment #142)
> (In reply to comment #138)
> 
> Ik bedoel, hoe we het in het Nederlands vertalen staat ter discussie, maar het
> verschil in het Engels is zoals ik het uitleg :).

Ik had het idee dat wat je zei slechts een voorbeeld was, of beter gezegd niet
omkeerbaar (koe/beest etc.), en daarbij klonk je wat ehm.. vul maar in.

> De set wordt ook veranderd.

Ok, dat is dan nieuw voor me. Mag ik aannemen dat dit belangrijker is (of dat
jij dit belangrijker vindt) dan de codering?

> Wat ik duidelijk probeer te maken is dat 1. in het Engels er historisch gezien
> zelden onderscheid tussen wordt gemaakt, en belangrijker dat 2. er in het
> Nederlands historisch gezien zo goed als nooit onderscheid tussen wordt gemaakt.

Dat snijdt hout, en had ik ook begrepen. Ik hou alleen niet zo van vaagheden,
vooral wat vertalingen betreft. :)

> Oh, nouja, er stond nog een voorbeeld bij. Het heeft in ieder geval niks met een
> verschil tussen bron en browser te maken.

Bedoel(de) je (eerder) mijn bewering over de gedetecteerde en/of handmatig
ingestelde codering t.o.v. de paginabron?

> Het gaat om het feit dat je zelf termen gaat bedenken omdat je blijkbaar een
> perfecte mapping met de Engelse terminologie wilt. Zelf termen bedenken is niet
> goed, als het vermeden kan worden.

Hoho, niet zeggen dat ik termen ga bedenken; tekencodering bestaat al langer en
zoals gezegd had ik ook twijfels over het set-deel. Karaktercodering heb ik ook
niet verzonnen, maar ik begrijp wel waar je heen wilt. Met een 1-op-1-mapping is
echter niets mis, zolang het toevallig klopt uiteraard, maar dat heeft niets te
maken met zelf bedenken.

> > Omdat? Dit vind ik nou net de belangrijkste vraag. :)
> 
> Omdat je het ter plekke bedenkt.

Aii, doe je het wéér.. (mij vertellen wat ik doe; daar hou ik niet van en jij
waarschijnlijk ook niet). Zeg dan op zijn minst dat het daar op lijkt o.i.d.

Maar goed, ik zal maar niet meer vragen naar een goede weerlegging van de
vertaling naar tekencodering.

> Ook Microsoft kan het fout doen.

Gebeurt echter zelden.

> Character encoding als karaktercodering
> vertalen ligt op het eerste gezicht het meest voor de hand, dus ik kan een
> dergelijke vertaling wel begrijpen, maar ik ben het er niet mee eens.

Dat is inmiddels duidelijk. Ik begrijp alleen niet (en vind het zelfs jammer,
echt waar) dat je de enige lijkt te zijn.

> Overigens gebruikt Microsoft in IE ‘codering’, dus dat geeft ook maar weer eens
> aan dat zij daar geen consistentie in hebben.

Klopt, maar dat is een geoorloofde inkorting omdat het nog steeds over een
codering van de tekens (of zelfs tekenset) gaat. Liever zag ik daarom in FF ook
codering, en met mij wellicht nog een hoop andere gebruikers.

> (In reply to comment #140)
> 
> We doen dit al sinds Firefox 1.0 en hebben er nog geen één klacht over gehad.

Ik baseer mijn uitspraak op de problemen van pre-1.0 en zoals ze voorkwamen in
het genoemde topic, dus helemaal onzin is het niet. Dergelijke problemen wil ik
nu gewoon voorkomen, niks mis mee toch?

> Alle fonts hebben deze ‘ ’ tekens ook gewoon, vziw.

Ik kan me vergissen maar volgens mij komt dit type aanhalingstekens tot nu toe
niet voor. I.i.g. de eerste niet. Maar daar ging het ook niet om, wel over het
niet verschijnen van curly aanhalingstekens/apostrofs en verkeerde code.

> Als ik een probleem met
> spacing zag lag dat altijd aan het gebruik van een accent ipv een aanhalingsteken.

Maar ook de 8217-gevallen e.d. als ik me niet vergis. Dit is ook een
aanhalingsteken, maar toch geen juiste code. En geeft het geen problemen dan is
het op zijn minst inconsistent.

> Overigens geeft het feit dat tekensetcodering ook 70 resultaten geeft maar weer
> aan dat als er iets fout gedaan kan worden, dat dat ook gebeurt :).

En dat kan makkelijk erger worden. * :)

> Maar goed:
> 
> tekensetcodering - 70 resultaten
> tekencodering    - 225 resultaten
> karaktercodering - 238 resultaten
> tekenset         - 17400 resultaten  * ;)
> 
> Dan maak je mij toch niet wijs dat tekenset niet de juiste vertaling is.

Dit is pas onzinnig. Je weet toch dat een tekenset van origine een character set
is? Dat begrip bestaat al sinds ver voordat er browsers bestonden, los van de
codering. Geen wonder dat daar meer resultaten op zijn te vinden; het zijn lang
niet allemaal letterlijke vertalingen van 'character encoding'. Naar mijn idee
reden te meer om het begrip niet te gebruiken, maar allá. :)


    
    

    
  
(In reply to comment #145)
> Het is overigens helemaal geen optie om in TB de apostrof niet te vervangen,
> daar er een stuk gedeelde code is waar die in voorkomt, zie bijvoorbeeld het
> koppelingetje `meer thema’s verkrijgen’ in de themabeheerder, die in toolkit
zit...

Had het gezien en er zijn geloof ik wel meer van dit soort gevallen. Maar zoals
gezegd was ik er niet op tegen en verwachtte de introductie ervan ooit wel,
alleen nu nog niet.

Valt me overigens op dat in de genoemde string in het screenshot wel een curly
apostrof te zien is. Is dat het geval met de huidige code en ziet het er bij
iedereen zo uit?

Hoewel dit een string met een curly erin in een .dtd betreft (en dus geen \u00B4
of \u2019) ziet het er hier toch uit zoals omschreven, dus mijn 'probleem' zou
weleens te maken kunnen hebben met het gebruikte OS.

Overigens heb ik nog geen 'breedteproblemen' zoals genoemd ervaren met dit
venster, noch met de themabeheerder, maar dat kan aan de gebruikte resolutie liggen.

    
    

    
  
(In reply to comment #144)
> (In reply to comment #143)
> 
> De extensiebeheerder ziet er hier overigens goed uit.

Voor alle duidelijkheid: dit probleem doet zich enkel voor in Thunderbird, en
wel doordat er daar een knop meer in de themabeheerder zit.  En ja, dat is een
curly quote daar.

Kan wat dat betreft eens een duidelijke richtlijn afgesproken worden?  Worden
aanhalingstekens bv. ook met krulletjes gemaakt, of alleen de apostrof? En is
een aanhalingsteken openen dan ` of nog iets anders (<- dat is de accent grave
op mijn qwerty maar dan zonder letter, op deze linux kan ik die curly quotes
niet produceren)?

    
    

    
  
(In reply to comment #146)
> > De set wordt ook veranderd.
> 
> Ok, dat is dan nieuw voor me. Mag ik aannemen dat dit belangrijker is (of dat
> jij dit belangrijker vindt) dan de codering?

De set en codering zijn aan elkaar gekoppeld. Geen UTF-8 zonder Unicode, geen
Unicode zonder UTF-8/16/32 en geen Latin-1 zonder... wel, Latin-1. Bij Latin-1
is er dus geen verschil.


> Dat snijdt hout, en had ik ook begrepen. Ik hou alleen niet zo van vaagheden,
> vooral wat vertalingen betreft. :)

Ik denk niet dat het vaag is. Het kleine onderscheid dat er in het Engels
bestaat vind ik juist vaag... In plaats van gewoon de terminologie te gebruiken
die er al tientallen jaren voor bestaat, moet je er over nadenken en vervolgens
een andere, meer moderne term gaan gebruiken.


> > Oh, nouja, er stond nog een voorbeeld bij. Het heeft in ieder geval niks met
> > een verschil tussen bron en browser te maken.
> 
> Bedoel(de) je (eerder) mijn bewering over de gedetecteerde en/of handmatig
> ingestelde codering t.o.v. de paginabron?

Ik reageer hier inderdaad op:

"Inderdaad, ik doelde ook op de representatie / weergave. Of begrijp ik je nu
verkeerd?"

"[...] de gebruikte (en in het document vastgelegde) tekenset en de door een
browser gehanteerde (de)codering zijn wel degelijk verschillende dingen [...]"

Dit heeft er niets mee te maken, dat is het verschil tussen codering en
decodering. Character set en encoding geven beiden aan met welke tekenset het
document is geencodeerd (en hoe het dus gedecodeerd moet worden), en gegeven de
twee termen geeft character encoding meer specifiek aan wat er veranderd
(character set is zeg maar een subset van character encodings, zo kan je het zien).

De term character set is de oorspronkelijke term, en character encoding is
later, waarschijnlijk ten tijde van Unicode ontstaan. In Unicode is er een
verschil tussen de twee, en het is nodig onderscheid te maken voor de
specificatie. Die term is in het Engels ook meer algemeen overgenomen, dus in
Firefox wordt er ook over character encoding gesproken.


> Hoho, niet zeggen dat ik termen ga bedenken; tekencodering bestaat al langer

Nuja, getuige het aantal google hits voor tekencodering en tekenset is de
laatste toch echt de meer gangbare term :). Het feit dat enkele anderen volgens
dezelfde gedachtengang als jij character encoding naar tekencodering vertalen
betekent nog niet dat het een echte bestaande term is.


> Dat is inmiddels duidelijk. Ik begrijp alleen niet (en vind het zelfs jammer,
> echt waar) dat je de enige lijkt te zijn.

Hendrik heeft een patch gemaakt waarin deze verandering wordt toegepast, ik neem
dus aan dat hij het met mij eens is.

Verder ben ik blijkbaar ook de enige die de materie begrijpt.


> > (In reply to comment #140)
> > We doen dit al sinds Firefox 1.0 en hebben er nog geen één klacht over gehad.
> 
> Ik baseer mijn uitspraak op de problemen van pre-1.0 en zoals ze voorkwamen in
> het genoemde topic, dus helemaal onzin is het niet. Dergelijke problemen wil
> ik nu gewoon voorkomen, niks mis mee toch?

Ik zie daar geen enkele problemen. Het enige dat ik zie is dat jij daar een
aantal wijzigingen van ’ naar ' voorstelt. Waarom weet ik ook niet.


> > Alle fonts hebben deze ‘ ’ tekens ook gewoon, vziw.
> 
> Ik kan me vergissen maar volgens mij komt dit type aanhalingstekens tot nu toe
> niet voor. I.i.g. de eerste niet. Maar daar ging het ook niet om, wel over het
> niet verschijnen van curly aanhalingstekens/apostrofs en verkeerde code.

Het komt wel voor. Zie bijv. Extra / "Thema’s". Dit is Firefox 1.5 beta 1, maar
dat was ook al zo ten tijde van Firefox 1.0 (of nuja, erna, want de vertaling
liet toen nogal op zich wachten).

Wat bedoel je met niet ‘verschijnen’ van curly aanhalingstekens? Daar heb ik nog
nooit van gehoord.


> > Als ik een probleem met
> > spacing zag lag dat altijd aan het gebruik van een accent ipv een
aanhalingsteken.
> 
> Maar ook de 8217-gevallen e.d. als ik me niet vergis. Dit is ook een
> aanhalingsteken, maar toch geen juiste code. En geeft het geen problemen dan
> is het op zijn minst inconsistent.

Aanhalingsteken is in Unicode teken U+2019 (8217 decimaal). Ik quote:

"2019 ’ RIGHT SINGLE QUOTATION MARK
= SINGLE COMMA QUOTATION MARK
- this is the preferred character to use for apostrophe"

Zie: http://www.unicode.org/charts/PDF/U2000.pdf

Hier hebben we het voor Firefox 1.0 al over gehad, en we hebben zo besloten, en
ik voel er zeer weinig voor om dat nu terug te gaan draaien, noch om er helemaal
overnieuw een discussie over te beginnen.


> > tekensetcodering - 70 resultaten
> > tekencodering    - 225 resultaten
> > karaktercodering - 238 resultaten
> > tekenset         - 17400 resultaten  * ;)
> > 
> > Dan maak je mij toch niet wijs dat tekenset niet de juiste vertaling is.
> 
> Dit is pas onzinnig. Je weet toch dat een tekenset van origine een character
> set is? Dat begrip bestaat al sinds ver voordat er browsers bestonden, los van
> de codering. Geen wonder dat daar meer resultaten op zijn te vinden; het zijn
> lang niet allemaal letterlijke vertalingen van 'character encoding'. Naar mijn 
> idee reden te meer om het begrip niet te gebruiken, maar allá. :)

Het heeft niet specifiek met browsers te maken. Bovendien, het zijn niet zomaar
‘meer resultaten’. Het zijn er zeventien duizend, tegenover een schamele
tweehonderd.

Tekenset is in het Nederlands gewoon een klein beetje ambigu, maar dat is nou
eenmaal zo, het is niet erg en maakt het alleen maar makkelijker. Codering is
wat dat betreft ook ambigu, het kan zowel tekenset als encryptie of ander type
codering betekenen, dus wat dat betreft is dat niet echt een beter alternatief.

Affijn, codering alleen zoals Microsoft het in Office en Internet Explorer doet
vind ik geen fijne vertaling, omdat de verwijzing naar wat voor type codering
het is verdwijnt. Tekencodering en karaktercodering ben ik beiden niet gelukkig
mee, omdat het zulke lange woorden zijn en tekenset een veel gangbaarder woord
is dat dezelfde lading dekt.


~Grauw

    
    

    
  
(In reply to comment #147)
> Valt me overigens op dat in de genoemde string in het screenshot wel een curly
> apostrof te zien is. Is dat het geval met de huidige code en ziet het er bij
> iedereen zo uit?
> 
> Hoewel dit een string met een curly erin in een .dtd betreft (en dus geen \u00B4
> of \u2019) ziet het er hier toch uit zoals omschreven, dus mijn 'probleem' zou
> weleens te maken kunnen hebben met het gebruikte OS.

Dat is inderdaad een curly ’ quote, oftewel &#8216;, oftewel \u2019 in
properties files.

Kan jij misschien een screenshot maken van jouw betreffende probleem?


(In reply to comment #148)
> Kan wat dat betreft eens een duidelijke richtlijn afgesproken worden?  Worden
> aanhalingstekens bv. ook met krulletjes gemaakt, of alleen de apostrof?

Alles. Dus:
                                      Unicode    DTD     Properties
enkele aanhalingstekens openen  : ‘ / U+2018 / &#8216; / \u2018
enkele aanhalingstekens sluiten : ’ / U+2019 / &#8217; / \u2019
apostrof                        : ’ / U+2019 / &#8217; / \u2019
dubbele aanhalingstekens openen : “ / U+201C / &#8220; / \u201C
dubbele aanhalingstekens sluiten: ” / U+201D / &#8221; / \u201D

Waarbij de tekens zelf ook in de Unicode gecodeerde bestanden gebruikt mogen
worden. Dat wil zeggen, DTD files, maar niet .properties files (die zijn
-helaas- Latin-1).

We zouden zelfs (nog Nederlandser) „ en ” kunnen gebruiken, maar laat dat maar
even zitten :).


> En is
> een aanhalingsteken openen dan ` of nog iets anders (<- dat is de accent grave
> op mijn qwerty maar dan zonder letter, op deze linux kan ik die curly quotes
> niet produceren)?

Aanhalingsteken openen is ‘ (ALTGR+9 in Windows met internationaal keyboard) en
níet `. ` is een los accent, voor op een letter, en heeft niks met apostrophen
te maken en ziet er ook heel anders uit.


~Grauw

    
    

    
  
Ik heb op de Vertaalwoordenboek wiki-pagina een stuk toegevoegd over ons
accentgebruik (samenvatting van wat ik hier ook al heb gezegd):

http://www.mozbrowser.nl/wiki/index.php/Vertaalwoordenboek


~Grauw

    
    

    
  
Overigens, als ik naar de Themabeheerder kijk in Thunderbird, dan zie ik dat er
nu drie (!) verschillende ‘apostrofen’ gebruikt worden:

In het menu Extra: Thema's
In de titelbalk:   Thema´s
En onderaan:       Meer thema’s verkrijgen

Dat is een ongewenste situatie. Gelieve er dus op te letten.

De ‘smalheid’ van het betreffende scherm doet zich overigens ook hier voor. het
kan mijns inziens inderdaad geen kwaad om dat een paar procenten breder te maken.


~Grauw

    
    

    
  
(In reply to comment #151)
> http://www.mozbrowser.nl/wiki/index.php/Vertaalwoordenboek

Dankjewel voor de opklaring.  Ik heb er nog even aan toegevoegd dat die
alt-combo's alleen met qwerty werken.

Kan er iemand eens met een scriptje voor zorgen dat ook in TB en andere
bestanden eenvormigheid ontstaat?  Ik veronderstel dat dat script van FF1.0 nog
wel ergens te vinden moet zijn?

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Apostrofen patch (obsolete)
        — 
          — Splinter Review
      

    


  
Deze patch corrigeert voorkomens van accenten ipv aanhalingstekens (\u00B4), en
vervangt ook een heleboel apostrofen waar nog ' gebruikt werd naar ‘ en ’.

Ik heb de "’s niet vervangen, omdat we dat eigenlijk nergens doen. Worden ook
niet zoveel gebruikt. Vraag me af of we dat alsnog moeten doen, of maar even
moeten laten zitten?

Ook een paar kleine taalcorrecties tussendoor.


~Grauw

    
    

    
  
Oh, sorry, die patch heeft ook een aantal onnozele wijzigingen waarbij
hoofdletters in escapes veranderd worden naar kleine letters. Is de schuld van
de Eclipse property editor (die handig is omdat ik niet handmatig dingen hoef te
escapen, maar wat dit betreft dus weer onhandig blijkt te zijn).

Het maakt in principe niet uit, maar als je een nieuwe patch wil moet je maar
even een gil geven.


~Grauw

    
    

    
  
Comment on attachment 197555 [details] [diff] [review]
Apostrofen patch

Vergeet deze hele patch maar, de encoding is ook niet goed. Nieuwe patch komt.


~Grauw

        Attachment #197555 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcte apostrofen patch (obsolete)
        — 
          — Splinter Review
      

    


  
Deze keer wel goed.

    
    

    
  
(In reply to comment #153)
> Kan er iemand eens met een scriptje voor zorgen dat ook in TB en andere
> bestanden eenvormigheid ontstaat?  Ik veronderstel dat dat script van FF1.0
> nog wel ergens te vinden moet zijn?

Dat is niet geautomatiseerd destijds... Ik heb daarnet de hele l10n directory
(incl. Thunderbird, toch?) doorzocht op ' tekens, en als het goed is moet het
met deze patch allemaal goed zijn.


~Grauw

    
    

    
  
Noot: attachment 197560 [details] [diff] [review] is alleen toepasbaar op de branch, op de trunk is er zo
te zien een regel in mime.properties weggehaald die hij probeert aan te passen.
Zo nodig kan ik een ‘trunk’-versie van deze patch maken? Is daar een andere bug
voor, waar ik die kan attachen?


~Grauw

    
    

    
  
(In reply to comment #157)
> Created an attachment (id=197560) [edit]
> Correcte apostrofen patch
> 
> Deze keer wel goed.

Ben je zeker dat dit in firebird-toc.RDF mag?  Daar hadden we voordien al
problemen met &

"Nieuwe-paginainstellingen": hier moet het streepje wel degelijk tussen de a en
de i, ai is namelijk een tweeklank.  Als je per se een streepje na nieuwe wilt,
dan moeten het er twee zijn.

+<!ENTITY  pageColorHeader           "Standaard pagina-uiterlijk">
uiterlijk vind ik alleen toepasselijk voor mensen, komt me hier een beetje
vreemd voor.  Wat is er mis met uitzicht? Hm, ja ook niet perfect, maar toch beter.

+nick_template=%1$s\u2019s %2$s ID
+nick_template_with_num=%1$s\u2019s %2$s ID #%3$d
Dit lijkt me geen goede vertaling, beter iets als %2$s ID van %1$s en analoog tweede

Ééntje vergeten: 
<!ENTITY mozilla.quote 'And so at last the beast

    
    

    
  
(In reply to comment #160)
> Ben je zeker dat dit in firebird-toc.RDF mag?  Daar hadden we voordien al
> problemen met &

& moet &amp; zijn, als je dat bedoelt, omdat het XML is.

Unicode mag: er staat <?xml version="1.0" encoding="UTF-8"?> bovenaan de file.


> "Nieuwe-paginainstellingen": hier moet het streepje wel degelijk tussen de a en
> de i, ai is namelijk een tweeklank.  Als je per se een streepje na nieuwe wilt,
> dan moeten het er twee zijn.

Ook goed. Nieuwe moet iig verbonden zijn aan pagina.

Ik heb het lokaal aangepast, het komt er bij de volgende patch doorheen. Laat
dat echter het inchecken van deze patch niet weerhouden.


> +<!ENTITY  pageColorHeader           "Standaard pagina-uiterlijk">
> uiterlijk vind ik alleen toepasselijk voor mensen, komt me hier een beetje
> vreemd voor.  Wat is er mis met uitzicht? Hm, ja ook niet perfect, maar toch
> beter.

Uitzicht leek echt nergens op. Dat zeg je niet. "Ooh dat pagina-uitzicht is zo
mooi!". Het Engels is "Standard Page Appearance.". Appearance vertaal je als
uiterlijk, niet uitzicht. Hier ga ik niet eens verder op in :).


> +nick_template=%1$s\u2019s %2$s ID
> +nick_template_with_num=%1$s\u2019s %2$s ID #%3$d
> Dit lijkt me geen goede vertaling, beter iets als %2$s ID van %1$s en analoog
tweede

Ik heb daar niks veranderd behalve de apostrof. Ik weet verder ook niet hoe dat
wordt gebruikt, en waar die string uberhaupt voorkomt. Als je dat wilt
veranderen, doe dat dan in een afzonderlijke patch.


> Ééntje vergeten: 
> <!ENTITY mozilla.quote 'And so at last the beast

Nee, die quote hoort bij de markup, en die moet dus niet vervangen worden want
dan maak je de pagina stuk. Daar moet je dus mee uitkijken, ook bij een evt.
aanpassing van " quotes, als we dat gaan doen. Ook staan er vaak (Engelse)
editor’s comments in, die ook intact moeten blijven. Dat is een belangrijke
reden waarom het proces lastig te automatiseren is.


~Grauw

    
    

    
  
(In reply to comment #161)
> > +<!ENTITY  pageColorHeader           "Standaard pagina-uiterlijk">
> > uiterlijk vind ik alleen toepasselijk voor mensen, komt me hier een beetje
> > vreemd voor.  Wat is er mis met uitzicht? Hm, ja ook niet perfect, maar toch
> > beter.
> 
> Uitzicht leek echt nergens op. Dat zeg je niet. "Ooh dat pagina-uitzicht is zo
> mooi!". Het Engels is "Standard Page Appearance.". Appearance vertaal je als
> uiterlijk, niet uitzicht. Hier ga ik niet eens verder op in :).

Uh, toch maar wel :).

Dat uiterlijk alleen toepasselijk voor mensen is, daar ben ik het niet mee eens.
Het is hoe dan ook beter dan ‘uitzicht’, wat gewoon incorrect is. Een pagina
heeft geen ‘uitzicht’. Uitzicht is als je ver kan kijken, en dan iets moois
ziet. Waarschijnlijk hierop gekomen omdat ‘view’ een synoniem is voor
‘appearance’ en ‘view’ onder meer als uitzicht vertaald kan worden?

Andere, correcte vertalingen van appearance zouden evt. ‘voorkomen’ of
‘presentatie’ kunnen zijn. Maar pagina-voorkomen vind ik vreemder dan
pagina-uiterlijk. Maar het maakt mij verder niet zoveel uit, zolang het maar
geen uitzicht is.


~Grauw

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Wederom, apostrofen patch (obsolete)
        — 
          — Splinter Review
      

    


  
(In reply to comment #162)
> Andere, correcte vertalingen van appearance zouden evt. ‘voorkomen’ of
> ‘presentatie’ kunnen zijn.

Heb het lokaal veranderd in pagina-presentatie. In de volgende patch komt dat
erdoor. Als je nog suggesties heb hoor ik ze graag.

Ondertussen heb ik het uit de patch gehaald, zodat deze er niet door wordt
opgehouden. Hier is de nieuwe, ook met de nieuwe-pagina-instelling wijziging.


~Grauw

        Attachment #197560 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #149)
> (In reply to comment #146)
> 
> Ik denk niet dat het vaag is. Het kleine onderscheid dat er in het Engels
> bestaat vind ik juist vaag... In plaats van gewoon de terminologie te gebruiken
> die er al tientallen jaren voor bestaat, moet je er over nadenken en vervolgens
> een andere, meer moderne term gaan gebruiken.

Zit wel wat in, maar dat geldt natuurlijk voor mensen die er aardig mee bekend
zijn. De doorsnee gebruiker ziet misschien vaker 'encoding' in (eerder
gebruikte) Engelse FF-versies en 'codering' in IE en krabt zich dan op zijn hoofd.

> Dit heeft er niets mee te maken, dat is het verschil tussen codering en
> decodering. Character set en encoding geven beiden aan met welke tekenset het
> document is geencodeerd (en hoe het dus gedecodeerd moet worden), en gegeven de
> twee termen geeft character encoding meer specifiek aan wat er veranderd
> (character set is zeg maar een subset van character encodings, zo kan je het
zien).

Ok. Ik krijg nu een beetje het idee dat we toch hetzelfde bedoelen. Wil daar dus
nog wel iets over zeggen/vragen maar doe dat nog wel eens op IRC anders levert
het vast opnieuw verwarring op en de bug is al lang genoeg.

> Nuja, getuige het aantal google hits voor tekencodering en tekenset is de
> laatste toch echt de meer gangbare term :). Het feit dat enkele anderen volgens
> dezelfde gedachtengang als jij character encoding naar tekencodering vertalen
> betekent nog niet dat het een echte bestaande term is.

http://www.winkelspel.nl/nonfood/45deligetekenset.html ? :)

> Hendrik heeft een patch gemaakt waarin deze verandering wordt toegepast, ik neem
> dus aan dat hij het met mij eens is.

Lijkt me meer een kwestie van je houden aan het vertaalwoordenboek op
mozilla-nl, wat ik ook had kunnen doen. Of hij het ermee eens is kon hij beter
zelf zeggen.

> Verder ben ik blijkbaar ook de enige die de materie begrijpt.

Ahum..

> Ik zie daar geen enkele problemen. Het enige dat ik zie is dat jij daar een
> aantal wijzigingen van ’ naar ' voorstelt. Waarom weet ik ook niet.

Dan keek je zeker met je neus. Het gaat hier maar om 1 geval, waarin een
8217-notatie volgens mij ten onrechte voorkomt in een .dtd. Dat dit toevallig
een ' wordt was vziw tot nu toe normaal in TB. Gelieve dus iets beter te kijken
alvorens zoiets te beweren. Je zou inmiddels ook beter moeten weten..

> Het komt wel voor. Zie bijv. Extra / "Thema’s". Dit is Firefox 1.5 beta 1, maar
> dat was ook al zo ten tijde van Firefox 1.0 (of nuja, erna, want de vertaling
> liet toen nogal op zich wachten).

De curly apostrof zoals in 'Thema’s' kwam wel voor ja, maar vziw niet als
aanhalingsteken, noch de ‘. Ik begin te geloven dat je iets te vaak iets wat ik
zeg in twijfel wil trekken zodra je maar een 'klepel' ziet. :)

> Wat bedoel je met niet ‘verschijnen’ van curly aanhalingstekens? Daar heb ik nog
> nooit van gehoord.

Dat een in code gebruikte curly apostrof (2019) op het scherm verschijnt als een
accent aigu zeg maar. Wel 'schuin' dus, maar zonder krul, en soms te breed.
Hetzelfde gebeurt op deze pagina (bv. het tabelletje in comment 150), maar dat
is wellicht normaal. Of toch niet?

> Aanhalingsteken is in Unicode teken U+2019 (8217 decimaal). Ik quote:
> 
> "2019 ’ RIGHT SINGLE QUOTATION MARK
> = SINGLE COMMA QUOTATION MARK
> - this is the preferred character to use for apostrophe"

Heb ik geloof ik destijds ook gepost en is geen nieuws, zie boven. Nogmaals, het
gaat in start.dtd alleen om de notatie en niet om het teken zelf. Wel blij dat
je het bovenstaande (en het bijbehorende verhaal in comment 150) noteert,
bespaart mij werk. :)

> Hier hebben we het voor Firefox 1.0 al over gehad, en we hebben zo besloten, en
> ik voel er zeer weinig voor om dat nu terug te gaan draaien, noch om er helemaal
> overnieuw een discussie over te beginnen.

Je zal inmiddels begrijpen dat ik niet uit was op 'iets terugdraaien', noch op
een discussie daarover. Tenzij je doelt op het voorstel tot enkel op sommige
plaatsen toepassen van de curly's, maar dan is dat dus vanwege het
weergaveprobleem. Maar dat heeft wellicht een andere (of lokale) oorzaak,
waarmee dat voorstel uiteraard vervalt.

> Het heeft niet specifiek met browsers te maken. Bovendien, het zijn niet zomaar
> ‘meer resultaten’. Het zijn er zeventien duizend, tegenover een schamele
> tweehonderd.

Zie boven. :)

> Tekenset is in het Nederlands gewoon een klein beetje ambigu, maar dat is nou
> eenmaal zo, het is niet erg en maakt het alleen maar makkelijker. Codering is
> wat dat betreft ook ambigu, het kan zowel tekenset als encryptie of ander type
> codering betekenen, dus wat dat betreft is dat niet echt een beter alternatief.

Tja.. dat makkelijker leek mij juist het geval voor codering, ook omdat het
begrip niet echt fout leek, afgezien van de genoemde verwarring. Nou ja, ik heb
er inmiddels vrede mee. Complimenten voor de uitleg.

> Affijn, codering alleen zoals Microsoft het in Office en Internet Explorer doet
> vind ik geen fijne vertaling, omdat de verwijzing naar wat voor type codering
> het is verdwijnt. Tekencodering en karaktercodering ben ik beiden niet gelukkig
> mee, omdat het zulke lange woorden zijn en tekenset een veel gangbaarder woord
> is dat dezelfde lading dekt.

Mooi gezegd. Had het eerder zo gedaan. ;)


    
    

    
  
(In reply to comment #164)

> http://www.winkelspel.nl/nonfood/45deligetekenset.html ? :)

LOL
 
> > Hendrik heeft een patch gemaakt waarin deze verandering wordt toegepast, ik neem
> > dus aan dat hij het met mij eens is.
> 
> Lijkt me meer een kwestie van je houden aan het vertaalwoordenboek op
> mozilla-nl, wat ik ook had kunnen doen. Of hij het ermee eens is kon hij beter
> zelf zeggen.

Wel, omdat je er expliciet naar vraagt: ik weet ook niet genoeg van de details
van de materie, maar ik ben meer voor de pragmatische taalkunde, ttz: ook al is
een vertaling ongelukkig gekozen, als ze ingeburgerd is, verander je er niks
meer aan.  En dat lijkt me hier voor tekenset het geval.

Maar ik ben nu wel nieuwsgierig naar het bezwaar tegen de term karakter...?

    
    

    
  


  
(In reply to comment #150)
> (In reply to comment #147)
> > Valt me overigens op dat in de genoemde string in het screenshot wel een
curly
> > apostrof te zien is. Is dat het geval met de huidige code en ziet het er
bij
> > iedereen zo uit?
> > 
> > Hoewel dit een string met een curly erin in een .dtd betreft (en dus geen
\u00B4
> > of \u2019) ziet het er hier toch uit zoals omschreven, dus mijn 'probleem'
zou
> > weleens te maken kunnen hebben met het gebruikte OS.
> 
> Dat is inderdaad een curly ’ quote, oftewel &#8216;, oftewel \u2019 in
> properties files.
> 
> Kan jij misschien een screenshot maken van jouw betreffende probleem?

Zie image. Huidige OS is Win98. Kan helaas niet zeggen hoe het er onder Linux
uitziet vanwege de vrij oude geïnstalleerde versie (waarin FF niet eens
werkt..) 

Misschien is de breedte van de apostrof in de string 'meer thema's verkrijgen'
lichtelijk overdreven maar ik heb toch het idee dat een curly er smaller
uitziet. Dit lijkt meer op te vallen in de titelbalk, waarin in Hendrik's
afbeelding óók geen curly te zien is. Of komt dat toevallig door een verkeerde
code? In het menu onder Extra die ik overigens ook geen curly.

> We zouden zelfs (nog Nederlandser) „ en ” kunnen gebruiken, maar laat dat
maar
> even zitten :).

Zijn die niet alleen voor uitspraken bedoeld? Als er hier al gequote wordt gaat
het meestal om foldernamen e.d.

    
    

    
  
(In reply to comment #165)
> 
> Maar ik ben nu wel nieuwsgierig naar het bezwaar tegen de term karakter...?

Ik zag daar een interessante uitspraak over op
http://mail.kde.org/pipermail/kde-i18n-nl/2005-March/005138.html en wil me daar
wel bij aansluiten, alhoewel men daarin vergelijkt met 'letterteken'. T.o.v.
'teken' zou ik de voorkeur geven aan 'karakter'.

Om nog even terug te komen op de breedte van het themavenster in TB: heb je
weleens gekeken wat er gebeurt als je de grootte handmatig aanpast en daarna TB
opnieuw start? Als het goed is wordt de grootte namelijk onthouden. Neemt niet
weg dat als een standaardinstelling is aan te passen, er volgens mij geen
bezwaar is dat ook te doen, maar noodzakelijk is het blijkbaar niet.


    
    

    
  
(In reply to comment #89)
> Created an attachment (id=196565) [edit]
> herschikkingen van preferences en ook wijzigingen

mail/chrome/messenger/preferences/changeaction.dtd
-<!ENTITY  changeAction.title                  "Actie veranderen">
+<!ENTITY  changeAction.title                  "Actie wijzigen">

Was dit niet eerder overal gewijzigd naar 'veranderen'? Hoewel 'wijzigen' niet
misstaat lijkt het me niet handig het nu in dit ene geval om te gooien, tenzij
het overal gebeurt. Ook ontstaan er dan problemen met access keys, die nu
nagenoeg allemaal goed werken.

mail/chrome/messenger/preferences/compose.dtd
-<!ENTITY useMIME.label                        "'Quoted printable' MIME-codering
gebruiken voor berichten die 8-bit tekens bevatten.">
+<!ENTITY useMIME.label                        "`Quoted printable’
MIME-codering gebruiken voor berichten die 8-bittekens bevatten.">

Klopt het dat het ene aanhalingsteken leesbaar is en de ander niet? (Is
inmiddels achterhaald door Laurens' patch). '8-bit tekens' lijkt me meer een
woordgroep (dus geen gevalletje '24-uurseconomie' o.i.d.), eventueel als
'8-bits', dus met spatie.

-<!ENTITY wrapOutMsg.label                     "Platte-tekstberichten afbreken op">
+<!ENTITY wrapOutMsg.label                     "Platte-tekstberichten afbreken na">

Ik twijfel sterk, lijkt mij te letterlijk, dan wel meer Vlaams.

mail/chrome/messenger/preferences/fonts.dtd
-<!ENTITY  typefaces.label                         "Typeface">
+<!ENTITY  typefaces.label                         "Lettertype">

Begrijp ik goed dat hiermee zowel font als typeface geoorloofd als lettertype
worden vertaald? De wiki maakt een onderscheid..

-<!ENTITY  font.langGroup.canadian                 "Verenigd Canadees
syllabeschrift">
+<!ENTITY  font.langGroup.canadian                 "Veralgemeend Canadees
syllabeschrift">

Ik zie 'veralgemeend' niet zitten (Vlaams?) en dacht bovendien dat dit 'Canadees
Aboriginal schrift' zou worden?

mail/chrome/messenger/preferences/general.dtd
-<!ENTITY selectWindowLayout.label         "Selecteer de gewenste
vensterindeling voor E-mail.">
+<!ENTITY selectWindowLayout.label         "Selecteer de gewenste
vensterindeling voor e-mail.">

Aangezien het om onderdelen van het programma gaat lijkt het me handiger de
hoofletters voor E-mail, Nieuws in dit soort kreten te behouden.

mail/chrome/messenger/preferences/notifications.dtd
-<!ENTITY customsound.label                "Aangepast .wav-bestand">
+<!ENTITY customsound.label                "Persoonlijk .wav-bestand">

Zou het liever zo houden, maar alla.

mail/chrome/messenger/preferences/preferences.properties
-saveToDisk=Opslaan naar schijf
+saveToDisk=Opslaan op schijf

Iedereen het hier mee eens?

Ik zie dat in dit bestand de escape-karakters (\) voor de ':' worden verwijderd.
Kan iemand duidelijkheid geven over of ze nu wel of niet nodig zijn voor
dergelijke karakters? Het leek mij nl. ook van niet, maar ik heb ze erin gelaten
omdat ik dacht dat ze wel nodig waren zodra er naast de : nog trema's o.i.d
voorkomen in het bestand. Vreemde gedachtengang misschien (unicode is unicode)
en misschien is dit een scriptkwestie geweest, maar goed.

mail/chrome/messenger/preferences/privacy.dtd
-<!ENTITY certificatesInfo.label ..
+<!ENTITY certificatesInfo.label .. -> beveiligingsapparaten

Rest OK

    
    

    
  
(In reply to comment #168)
> (In reply to comment #89)
> > Created an attachment (id=196565) [edit] [edit]
> > herschikkingen van preferences en ook wijzigingen
> Was dit niet eerder overal gewijzigd naar 'veranderen'? Hoewel 'wijzigen' niet

Uh, ja niet over nagedacht, ik vind het gewoon beter klinken.  Ik probeer in het
algemeen wel op acces keys te letten.  Ik leg me neer bij de consensus, dus ik
veronderstel `veranderen'?

> +<!ENTITY useMIME.label                        "`Quoted printable’
> Klopt het dat het ene aanhalingsteken leesbaar is en de ander niet? (Is
> inmiddels achterhaald door Laurens' patch). 

Ja, ik zie hier een hele hoop conflicten ontstaan op het moment dat de
apostroffenpatch doorgevoerd wordt, daar ik een hele hoop lokale wijzigingen
heb.  Dit is er eentje van.  Ik veronderstel dat ik de patch toch nieuw moet
maken, dan zorg ik ervoor dat de accenten in orde zijn.

'8-bit tekens' lijkt me meer een
> woordgroep (dus geen gevalletje '24-uurseconomie' o.i.d.), eventueel als
> '8-bits', dus met spatie.

Waarop baseer je dat? Ik vind het net wél een geval 24-uurseconomie, maar dat
hangt er waarschijnlijk vanaf wat je met `geval' bedoelt.
 
> -<!ENTITY wrapOutMsg.label                     "Platte-tekstberichten afbreken
op">
> +<!ENTITY wrapOutMsg.label                     "Platte-tekstberichten afbreken
na">
> 
> Ik twijfel sterk, lijkt mij te letterlijk, dan wel meer Vlaams.

Je breekt het toch af na het zoveelste teken?  Hoe wil je `op' een teken
afbreken?  (Je moet dit in combinatie met de rest van de string zien!)

> Ik zie 'veralgemeend' niet zitten (Vlaams?) en dacht bovendien dat dit 'Canadees
> Aboriginal schrift' zou worden?

Hum, zo is het idd elders ook, dat moet gelijk getrokken worden, al denk ik niet
dat de Inuit het leuk zullen vinden om als aboriginal bestempeld te worden.

> vensterindeling voor e-mail.">
> 
> Aangezien het om onderdelen van het programma gaat lijkt het me handiger de
> hoofletters voor E-mail, Nieuws in dit soort kreten te behouden.

Niet mee eens.
 
> mail/chrome/messenger/preferences/notifications.dtd
> -<!ENTITY customsound.label                "Aangepast .wav-bestand">
> +<!ENTITY customsound.label                "Persoonlijk .wav-bestand">
> 
> Zou het liever zo houden, maar alla.

Maar het bestand is toch niet aangepast?  Het is een bestand dat je zelf kiest,
maar aan het bestand zelf verander je toch niks?  Customise betekent: aan je
wensen aanpassen, dat betekent echter niet dat alles wat customised is, ook
aangepast is!

> Ik zie dat in dit bestand de escape-karakters (\) voor de ':' worden verwijderd.

Ik heb de indruk dat deze escapes door het vroeger gebruikte vertaalprogramma
erin gezet zijn, met als resultaat dat je dingen als '\\\' krijgt waar in het
Engels gewoon '\' staat.  Ik werk gewoon consequent met de Engelse versie
ernaast op het scherm, en daar staan er nergens escapes, dus lijkt het me qua
`uncluttering' alleen maar goed als die in het nl weer verdwijnen.  (Een effect
dat jammer genoeg weer grotendeels bemoeilijkt wordt door de apostroffenpatch,
met al die \u201[89] ertussen, maar goed)


    
    

    
  
*** Betreffende de curly quotes ***

(In reply to comment #164)
> > Ik zie daar geen enkele problemen. Het enige dat ik zie is dat jij daar een
> > aantal wijzigingen van ’ naar ' voorstelt. Waarom weet ik ook niet.
> 
> Dan keek je zeker met je neus. Het gaat hier maar om 1 geval, waarin een
> 8217-notatie volgens mij ten onrechte voorkomt in een .dtd. Dat dit toevallig
> een ' wordt was vziw tot nu toe normaal in TB. Gelieve dus iets beter te kijken
> alvorens zoiets te beweren. Je zou inmiddels ook beter moeten weten..

Als jij in het vervolg wat specifieker naar een bepaald bericht van jouzelf
verwijst, bijv. met een directe link, dan weet ik misschien ook beter waar je
het over hebt.

Je kan niet van mij verwachten dat ik pagina’s lange forum threads ga doorlezen
puur en alleen omdat jij me iets duidelijk wil maken.


> De curly apostrof zoals in 'Thema’s' kwam wel voor ja, maar vziw niet als
> aanhalingsteken, noch de ‘. Ik begin te geloven dat je iets te vaak iets wat
> ik zeg in twijfel wil trekken zodra je maar een 'klepel' ziet. :)

Ik weet niet wat je wil zeggen dan. Je moet jezelf iets duidelijker maken.
Sowieso maakt het feit dat we het over twee dingen door elkaar hebben dingen
niet echt duidelijker.

Overigens heb ik juist frustratie dat ik gewoon weet waar ik het over heb, en
dat dat in twijfel wordt getrokken. Alsof ik de boel loop te bedotten.


> Dat een in code gebruikte curly apostrof (2019) op het scherm verschijnt als
> een accent aigu zeg maar. Wel 'schuin' dus, maar zonder krul, en soms te
> breed. Hetzelfde gebeurt op deze pagina (bv. het tabelletje in comment 150),
> maar dat is wellicht normaal. Of toch niet?

Ok. Zeg dat dan. Dat ligt dan blijkbaar aan je OS, die een dergelijke
‘vertaling’ toepast, omdat een ‘ en ’ zich niet in de karakterset die hij
gebruikt bevindt? Hier gebeurt dat niet in ieder geval.

Het lijkt me in ieder geval ‘normaal’.


> > Aanhalingsteken is in Unicode teken U+2019 (8217 decimaal). Ik quote:
> > 
> > "2019 ’ RIGHT SINGLE QUOTATION MARK
> > = SINGLE COMMA QUOTATION MARK
> > - this is the preferred character to use for apostrophe"
> 
> Heb ik geloof ik destijds ook gepost.

Uh, ik weet niet meer wat jij gepost hebt, maar ik heb dat destijds opgezocht.


> Je zal inmiddels begrijpen dat ik niet uit was op 'iets terugdraaien', noch op
> een discussie daarover. Tenzij je doelt op het voorstel tot enkel op sommige
> plaatsen toepassen van de curly's, maar dan is dat dus vanwege het
> weergaveprobleem. Maar dat heeft wellicht een andere (of lokale) oorzaak,
> waarmee dat voorstel uiteraard vervalt.

Wees dan wat duidelijker in je voorstel. Ik weet nu nog steeds niet wat je
bedoelt. "enkel op sommige plaatsen toepassen van de curly's"? Wélke plaatsen
dan? Maak er desnoods een aparte bug van.


(In reply to comment #167)
> > Maar ik ben nu wel nieuwsgierig naar het bezwaar tegen de term karakter...?
> 
> Ik zag daar een interessante uitspraak over op
> http://mail.kde.org/pipermail/kde-i18n-nl/2005-March/005138.html en wil me daar
> wel bij aansluiten

Helemaal mee eens.


~Grauw

    
    

    
  
(iek, de vorige was per abuis gepost, die moest hierna pas komen. awel.)

*** Betreffende de karakterset/tekenset/whatever ***

(In reply to comment #164)
> Zit wel wat in, maar dat geldt natuurlijk voor mensen die er aardig mee bekend
> zijn. De doorsnee gebruiker ziet misschien vaker 'encoding' in (eerder
> gebruikte) Engelse FF-versies en 'codering' in IE en krabt zich dan op zijn
> hoofd.

Ja, en een gebruiker die in het Engels gewend is ‘link’ te zien weet ook niet
wat koppeling betekent. Of hij heeft eerder tekensetcodering gezien en weet niet
wat dat betekent nu we dat gaan veranderen. Die doorsnee gebruiker weet toch
niet genoeg van de materie om op een zinnige wijze iets met de tekenset te doen.
Als je weet wat het is, dan weet je ook wat tekenset betekent. En dat het in het
verleden of in andere talen anders is geweest betekent niet dat we niet voor de
beste vertaling moeten gaan.


> Ok. Ik krijg nu een beetje het idee dat we toch hetzelfde bedoelen. Wil daar dus
> nog wel iets over zeggen/vragen maar doe dat nog wel eens op IRC anders levert
> het vast opnieuw verwarring op en de bug is al lang genoeg.

Ik zal kijken of ik vanavond op IRC kan zijn.


> http://www.winkelspel.nl/nonfood/45deligetekenset.html ? :)

Ja, ik had het gezien :).


> > Verder ben ik blijkbaar ook de enige die de materie begrijpt.
> 
> Ahum..

Nou, gezien de hoeveelheid uitleg die ik moet geven...


> > Het heeft niet specifiek met browsers te maken. Bovendien, het zijn niet zomaar
> > ‘meer resultaten’. Het zijn er zeventien duizend, tegenover een schamele
> > tweehonderd.
> 
> Zie boven. :)

Kijk dan naar:

http://www.google.nl/search?q=karakterset

11.200 resultaten. Daar zitten echt geen tekensetjes tussen.


> Tja.. dat makkelijker leek mij juist het geval voor codering, ook omdat het
> begrip niet echt fout leek, afgezien van de genoemde verwarring. Nou ja, ik heb
> er inmiddels vrede mee. Complimenten voor de uitleg.

Okee.


> Mooi gezegd. Had het eerder zo gedaan. ;)

No offense, maar ditzelfde heb ik op zijn minst al tien keer eerder gezegd.
Behalve dat stukje over het type codering. Wat alleen als argument dient tegen
het overnemen van de vertaling die Microsoft in IE gebruikt, wat nog niet eerder
ter sprake was gekomen.


(In reply to comment #167)
> > Maar ik ben nu wel nieuwsgierig naar het bezwaar tegen de term karakter...?
> 
> Ik zag daar een interessante uitspraak over op
> http://mail.kde.org/pipermail/kde-i18n-nl/2005-March/005138.html en wil me daar
> wel bij aansluiten

Helemaal mee eens.


~Grauw

    
    

    
  


  
(In reply to comment #166)
> > Kan jij misschien een screenshot maken van jouw betreffende probleem?
> 
> Zie image. Huidige OS is Win98. Kan helaas niet zeggen hoe het er onder Linux

> uitziet vanwege de vrij oude geïnstalleerde versie (waarin FF niet eens
> werkt..) 
>
> Misschien is de breedte van de apostrof in de string 'meer thema's
verkrijgen'
> lichtelijk overdreven maar ik heb toch het idee dat een curly er smaller
> uitziet. Dit lijkt meer op te vallen in de titelbalk, waarin in Hendrik's
> afbeelding óók geen curly te zien is. Of komt dat toevallig door een
verkeerde
> code? In het menu onder Extra die ik overigens ook geen curly.

Ik snap wat je bedoelt.

Ik heb een schermafdruk gemaakt (met ‘Cleartype’ uitgeschakeld, die de
horizontale fontresolutie verdriedubbelt op TFT schermen, en er dingen dus
anders uit laat zien). Hier bijgevoegd.

Als je mijn screenshot vergelijkt met de jouwe, zie je in de titelbalk bij mij
het verschijnsel dat de apostrof daar (een accent dus) écht teveel ruimte
inneemt. Daarbij vergeleken vind ik de ruimte in jouw screenshot nog wel
meevallen en niet storend, alhoewel zoals je in de tekst daaronder ziet de ’
bij mij inderdaad iets minder ruimte inneemt.

Maar welk accent Windows 98 nou echt gebruikt, dat weet ik niet. Wellicht ligt
het ook gewoon aan een verschil tussen het font dat Win98 gebruikt en dat van
WinXP.

In ieder geval, ik zie hier geen probleem met de quotes. Een dergelijk verschil
valt gewoon binnen de grenzen van wat normaal is, we hebben geen pixel-perfecte
controle over hoe dingen eruit zien. Zeker niet iets om ons apostrofen-gebruik
op aan te passen (als er nou vierkantjes ofzo hadden gestaan, of echt iets heel
verkeerds, dan had dat nog gekund omdat er dan blijkbaar onvoldoende support
voor curly quotes is in bepaalde OSen).


> > We zouden zelfs (nog Nederlandser) „ en ” kunnen gebruiken, maar laat dat
> > maar even zitten :).
> 
> Zijn die niet alleen voor uitspraken bedoeld? Als er hier al gequote wordt
> gaat het meestal om foldernamen e.d.

Dat weet ik niet... Volgens mij niet, ik heb nog nooit van zo’n soort regel
gehoord. Ik heb gewoon op de basisschool geleerd om dubbele aanhalingstekens
aan het begin onderaan te zetten, en op het eind bovenaan...


~Grauw

    
    

    
  
(In reply to comment #168)
> -<!ENTITY wrapOutMsg.label                     "Platte-tekstberichten afbreken
op">
> +<!ENTITY wrapOutMsg.label                     "Platte-tekstberichten afbreken
na">
> 
> Ik twijfel sterk, lijkt mij te letterlijk, dan wel meer Vlaams.

‘Op’ is goed. Het gebeurt op elke x karakters in een regel, en niet alleen na de
eerste x karakters. Niet eens met deze wijziging dus.


> mail/chrome/messenger/preferences/fonts.dtd
> -<!ENTITY  typefaces.label                         "Typeface">
> +<!ENTITY  typefaces.label                         "Lettertype">
> 
> Begrijp ik goed dat hiermee zowel font als typeface geoorloofd als lettertype
> worden vertaald? De wiki maakt een onderscheid..

Volgens mij wordt dit uberhaupt niet gebruikt in Thunderbird. Ik zou het zelf
voor de zekerheid dus maar zo laten, alhoewel Wikipedia bij ‘font’ naar
‘Typeface’ linkt, dus ik heb ook geen specifiek bezwaar tegen deze wijziging.


> -<!ENTITY  font.langGroup.canadian                 "Verenigd Canadees
> syllabeschrift">
> +<!ENTITY  font.langGroup.canadian                 "Veralgemeend Canadees
> syllabeschrift">
> 
> Ik zie 'veralgemeend' niet zitten (Vlaams?) en dacht bovendien dat dit
> 'Canadees Aboriginal schrift' zou worden?

Dit hebben we al eens eerder bekeken, weet niet of de uitkomst van destijds is
doorgevoerd.

Veralgemeend ben ik het niet mee eens.


> mail/chrome/messenger/preferences/preferences.properties
> -saveToDisk=Opslaan naar schijf
> +saveToDisk=Opslaan op schijf
> 
> Iedereen het hier mee eens?

Op zich wel.

Maar we moeten dat dan wel consistent gebruiken. Is dat het geval?


> Ik zie dat in dit bestand de escape-karakters (\) voor de ':' worden
> verwijderd.
> Kan iemand duidelijkheid geven over of ze nu wel of niet nodig zijn voor
> dergelijke karakters? Het leek mij nl. ook van niet, maar ik heb ze erin
> gelaten omdat ik dacht dat ze wel nodig waren zodra er naast de : nog trema's
> o.i.d voorkomen in het bestand. Vreemde gedachtengang misschien (unicode is
> unicode) en misschien is dit een scriptkwestie geweest, maar goed.

Niet nodig, denk ik. En anders merken we het snel genoeg.

.properties bestanden zijn *niet* Unicode.


(In reply to comment #169)
> '8-bit tekens' lijkt me meer een
> > woordgroep (dus geen gevalletje '24-uurseconomie' o.i.d.), eventueel als
> > '8-bits', dus met spatie.
> 
> Waarop baseer je dat? Ik vind het net wél een geval 24-uurseconomie, maar dat
> hangt er waarschijnlijk vanaf wat je met `geval' bedoelt.

8-bit tekens moet mét spatie, als je het mij vraagt.


> > Aangezien het om onderdelen van het programma gaat lijkt het me handiger de
> > hoofletters voor E-mail, Nieuws in dit soort kreten te behouden.
> 
> Niet mee eens.

Ditto.


> Maar het bestand is toch niet aangepast?  Het is een bestand dat je zelf kiest,
> maar aan het bestand zelf verander je toch niks?  Customise betekent: aan je
> wensen aanpassen, dat betekent echter niet dat alles wat customised is, ook
> aangepast is!

Klinkt logisch.


> (Een effect
> dat jammer genoeg weer grotendeels bemoeilijkt wordt door de apostroffenpatch,
> met al die \u201[89] ertussen, maar goed)

Ga klagen bij Sun, dat ze expliciet Latin-1 en geen Unicode voor die stomme
files hebben gespecificeerd.

Overigens: http://www.axel-hecht.de/blog/archives/000190.html


~Grauw

    
    

    
  
-          <li>Martijn Ras </li></ul>">
+          <li>Martijn Ras </li>
+          <li>Hendrik Maryns</li></ul>">

Het lijkt me beter om dit gewoon op het einde in ייn keer voor iedereen te doen.


-<!ENTITY window.title                      "Algemene clientinstellingen">
+<!ENTITY window.title                      "Standaardclient-instellingen">

Moet dit niet Standaardapplicatie zijn? (dat staat eronder namelijk)


~Grauw

    
    

    
  
(In reply to comment #173)
> (In reply to comment #168)
> ‘Op’ is goed. Het gebeurt op elke x karakters in een regel, en niet alleen na de
> eerste x karakters. Niet eens met deze wijziging dus.

Na elke x karakters.  Weet niet waar je het probleem ziet, ik vind het vreemd om
te zeggen dat je afbreekt `op een karakter'.  (Karakters?? => tekens!)

> > Begrijp ik goed dat hiermee zowel font als typeface geoorloofd als lettertype
> > worden vertaald? De wiki maakt een onderscheid..

Kan ik niet terugvinden,  maar mijn dikke Van Dale E-N geeft bij typeface 0.1
letterbeeld 0.2 lettertype/soort.  Omdat ik niet denk dat het eerste bedoeld
wordt, heb ik voor lettertype gekozen.

> > -<!ENTITY  font.langGroup.canadian                 "Verenigd Canadees
> > syllabeschrift">
> Dit hebben we al eens eerder bekeken, weet niet of de uitkomst van destijds is
> doorgevoerd.

Klopt, ik heb het nagekeken, in bug 297896 comment 105 staan (m.i. niet erg)
overtuigende argumenten voor Canadees Aboriginal Schrift, wat eigenlijk Canadees
aboriginalschrift zou moeten zijn.  Laten we het dan maar daarop houden.

> > +saveToDisk=Opslaan op schijf
> Maar we moeten dat dan wel consistent gebruiken. Is dat het geval?
Ik verander het consequent overal waar ik het tegenkom :-p

> (In reply to comment #169)
> > '8-bit tekens' lijkt me meer een
> > > woordgroep (dus geen gevalletje '24-uurseconomie' o.i.d.), eventueel als
> > > '8-bits', dus met spatie.
> > 
> > Waarop baseer je dat? Ik vind het net wél een geval 24-uurseconomie, maar dat
> > hangt er waarschijnlijk vanaf wat je met `geval' bedoelt.
> 
> 8-bit tekens moet mét spatie, als je het mij vraagt.

Argumenten graag.  Mijn argument is dat `x-bits' geen adjectief is. Meer nog:
het is precies zo opgebouwd als 24-uurseconomie: cijfer+zelfstandig naamwoord+s+znw.

    
    

    
  
(In reply to comment #174)
> Het lijkt me beter om dit gewoon op het einde in ייn keer voor iedereen te doen.

Tsja, ik ben een beetje ijdel...

> +<!ENTITY window.title                      "Standaardclient-instellingen">
> 
> Moet dit niet Standaardapplicatie zijn? (dat staat eronder namelijk)

Ja, lokaal aangepast, komt met revisie van vorige patch.

    
    

    
  
Comment on attachment 197249 [details] [diff] [review]
Infinitieven in installer.inc

Toegepast op trunk en branch

        Attachment #197249 -
        Attachment is obsolete: true

    
    

    
  


  
Dit is de complete map messenger, herschikt.  De patch bestaat voor 99.9% enkel
uit herschikkingen van de bestanden, en die paar wijzigingen die erin staan,
daar kan amper bezwaar tegen zijn: 
\: -> : in .properties
veiligheids -> beveiligings
en enkele spellingfouten.

Een tweede patch volgt met alle wijzigingen aan de tekst binnen deze map, maar
sommige kon ik er hier niet uithalen omdat het soms gemengd is.

        Attachment #196565 -
        Attachment is obsolete: true

        Attachment #196689 -
        Attachment is obsolete: true

    
    

    
  


  
Hier zijn door onoplettendheid van mij wijzigingen en herschikkingen door
elkaar geraakt.  Alleen het bovenste deel bevat wijzigingen, daaronder niet
meer.

    
    

    
  
(In reply to comment #178)
> Created an attachment (id=197915) [edit]
> Herschikkingen in mail/chrome/messenger

Het lijkt me een goed idee deze patch eerst uit te voeren en dan pas de andere,
daar hier vele dingen veranderd worden die daar ook veranderen.  Dit zal sowieso
een hele hoop hunks opleveren, en de andere patches zijn makkelijker om
conflicten op te lossen.  Vooral met de apostroffen voorspel ik problemen.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Wijzigingen in messenger (obsolete)
        — 
          — Splinter Review
      

    


  
Dit zijn wijzigingen die ik aan de bestanden maakte die al in de juiste
volgorde stonden.

- nog meer \ verwijderd
- resetten -> herinitialiseren
- het volgende -> de volgende: het betreft hier een meervoud
- default application
- meerdere spelfouten en aanmerkingen

    
    

    
  
Comment on attachment 197032 [details] [diff] [review]
xslt.properties (2-2)

patch toegepast op branch en trunk

        Attachment #197032 -
        Attachment is obsolete: true

    
  

        Attachment #197031 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 196780 [details] [diff] [review]
Correcties n.a.v. att 193552

toegepast op trunk en branch

        Attachment #196780 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 196781 [details] [diff] [review]
Correcties n.a.v. att. 193797

toegepast op branch en trunk

        Attachment #196781 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 196784 [details] [diff] [review]
Correcties n.a.v. att 194524

toegepast op branch en trunk

        Attachment #196784 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 197253 [details] [diff] [review]
Correcties n.a.v. att 194864 (2)

toegepast op branch en trunk

        Attachment #197253 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 197255 [details] [diff] [review]
Correcties n.a.v. att 195517 (2)

toegepast op branch en trunk, behalve:
-<!ENTITY charsetMenu.label "Tekenset">
+<!ENTITY charsetMenu.label "Tekensetcodering">
ivm de discussie

        Attachment #197255 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 197359 [details] [diff] [review]
Correcties tov en-US en wat andere kleine verbeteringen

toegepast op branch en trunk

        Attachment #197359 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #174)
> -          <li>Martijn Ras </li></ul>">
> +          <li>Martijn Ras </li>
> +          <li>Hendrik Maryns</li></ul>">
> 
> Het lijkt me beter om dit gewoon op het einde in ייn keer voor iedereen te doen.
> 
> 
> -<!ENTITY window.title                      "Algemene clientinstellingen">
> +<!ENTITY window.title                      "Standaardclient-instellingen">
> 
> Moet dit niet Standaardapplicatie zijn? (dat staat eronder namelijk)
> 
> 
> ~Grauw
~Grauw

zou je altijd "(In reply to comment #XXX)" erbij willen zetten (de reply link).
door de lengte van de bug (en dat ik het soms een paar dagen niet kan volgen)
zoek ik op comment nummers om te kijken of er een reactie op een aangeboden patch.

bedankt

    
    

    
  
Comment on attachment 197368 [details] [diff] [review]
tekenset, offlinegebruik en andere kleinere dingen

patching file mail/chrome/messenger/msgSynchronize.dtd
Hunk #1 FAILED at 1.
patching file mail/chrome/messenger/preferences/general.dtd
Hunk #3 FAILED at 36.

verdre toegepast op branch en trunk

        Attachment #197368 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #189)
> (In reply to comment #174)
> zou je altijd "(In reply to comment #XXX)" erbij willen zetten (de reply link).
> door de lengte van de bug (en dat ik het soms een paar dagen niet kan volgen)

Dit ging om de patch hieronder, is echter niet zo erg, de tweede opmerking is
bij mij lokaal al aangepast, en zit ook in mijn laatste patch, maar zal daardoor
een hunk geven (omdat de oorspronkelijke veranderd is).  Eigenlijk wel erg dus.
 Maar ik kan gerust een nieuwe maken, dat zal wegens overlappingen sowieso nodig
zijn.

(In reply to comment #190)
> (From update of attachment 197368 [details] [diff] [review] [edit])
> patching file mail/chrome/messenger/msgSynchronize.dtd
> Hunk #1 FAILED at 1.

Zal ik in nieuwe patch steken.

> patching file mail/chrome/messenger/preferences/general.dtd
> Hunk #3 FAILED at 36.

Niet erg.

    
    

    
  
Wil je een nieuwe apostrofen patch, met de conflicten tot dusver geresolved? Of
moet ik voor de wijzigingen die niet doorkomen achteraf maar gewoon weer een
nieuwe patch maken?


~Grauw

    
    

    
  
(In reply to comment #192)
> Wil je een nieuwe apostrofen patch, met de conflicten tot dusver geresolved? Of
> moet ik voor de wijzigingen die niet doorkomen achteraf maar gewoon weer een
> nieuwe patch maken?
> 
> 
> ~Grauw

komende week heb ik geen tijd om de patches toetepassen. volgens mij is het
handig als je een nieuwe patch maakt als ik de openstaande patches heb verwerkt
(volgend weekend)

dank

MM

    
    

    
  
(In reply to comment #169)
> 
> Uh, ja niet over nagedacht, ik vind het gewoon beter klinken.  Ik probeer in het
> algemeen wel op acces keys te letten.  Ik leg me neer bij de consensus, dus ik
> veronderstel `veranderen'?

Van mij mag het overal 'wijzigen' worden, vind het ook beter als het gaat om een
actie.

> '8-bit tekens' lijkt me meer een
> > woordgroep (dus geen gevalletje '24-uurseconomie' o.i.d.), eventueel als
> > '8-bits', dus met spatie.
> 
> Waarop baseer je dat? Ik vind het net wél een geval 24-uurseconomie, maar dat
> hangt er waarschijnlijk vanaf wat je met `geval' bedoelt.

Gevoelsmatig, maar als je argumenten wilt zal het denk ik neerkomen op valentie
(zie o.a. http://taalunieversum.org/taal/advies/tekst/9/). Zie het maar als
8-bit(s) 'brede' karakters. Zoiets ligt anders bij 24-uurseconomie.

> > ["Platte-tekstberichten afbreken op">]
> > 
> > Ik twijfel sterk, lijkt mij te letterlijk, dan wel meer Vlaams.
> 
> Je breekt het toch af na het zoveelste teken?  Hoe wil je `op' een teken
> afbreken?  (Je moet dit in combinatie met de rest van de string zien!)

Dit is denk ik toch een verschil tussen Nederlands en Vlaams. Zie het maar zo
dat Nederlanders spreken over "afbreken op [een bepaalde positie die ligt bij] x
karakters". Je redenatie is dus niet verkeerd, alleen letterlijk en hier nu
eenmaal niet zo gebruikelijk. Nooit opgevallen in andere programma's?

> > Aangezien het om onderdelen van het programma gaat lijkt het me handiger de
> > hoofletters voor E-mail, Nieuws in dit soort kreten te behouden.
> 
> Niet mee eens.

Ok dan.

> Maar het bestand is toch niet aangepast?  Het is een bestand dat je zelf kiest,
> maar aan het bestand zelf verander je toch niks?  Customise betekent: aan je
> wensen aanpassen, dat betekent echter niet dat alles wat customised is, ook
> aangepast is!

Weet ik en dat vond ik ook, maar je moet het dan zien als een 'aangepaste
instelling', niet het bestand zelf. Door het afwezige 'instelling' ziet het er
echter wel zo uit dus ideaal is het idd niet, maar 'persoonlijk' leek me wat te
'kenmerkend' en te veel afwijken van de originele tekst, waar meer 'afwijkend'
wordt bedoeld. Maar wellicht is het toch beter. Vergeet alleen niet de access key..


    
    

    
  
(In reply to comment #170)
> *** Betreffende de curly quotes ***
> 
> Als jij in het vervolg wat specifieker naar een bepaald bericht van jouzelf
> verwijst, bijv. met een directe link, dan weet ik misschien ook beter waar je
> het over hebt.

Hè ja, natuurlijk ligt het niet aan jou. :)

Ik wijs je er bij deze nogmaals op dat het begon met comment #127 en alleen over
die ene 8217 ging. Dat is heel wat anders dan "Ik zie daar geen enkele
problemen. Het enige dat ik zie is dat jij daar een aantal wijzigingen van ’
naar ' voorstelt. Waarom weet ik ook niet."

> Je kan niet van mij verwachten dat ik pagina’s lange forum threads ga doorlezen
> puur en alleen omdat jij me iets duidelijk wil maken.

Dat hoefde ook niet en ik verwacht helemaal niks van je, behalve dat áls je
commentaar levert, je wel eerst goed leest waar het over gaat (inclusief de
betreffende patch) en bovendien zelf duidelijk aangeeft waarop je reageert.
Hetzelfde dus als wat je van anderen verwacht.

> > De curly apostrof zoals in 'Thema’s' kwam wel voor ja, maar vziw niet als
> > aanhalingsteken, noch de ‘. Ik begin te geloven dat je iets te vaak iets wat
> > ik zeg in twijfel wil trekken zodra je maar een 'klepel' ziet. :)
> 
> Ik weet niet wat je wil zeggen dan. Je moet jezelf iets duidelijker maken.
> Sowieso maakt het feit dat we het over twee dingen door elkaar hebben dingen
> niet echt duidelijker.

Zelfde verhaal, hierin heb je me ook niet goed begrepen. Misschien gebruik ik
soms te veel woorden ja, wat niet altijd bevordelijk is voor de communicatie en
dat wil ik best toegeven, maar als jij daar moeite mee hebt zijn er betere (en
vooral beleefdere) manieren om dat duidelijk te maken en er bovendien vanuit te
gaan dat de ander per definitie fout zit en onzinvoorstellen doet.

> Overigens heb ik juist frustratie dat ik gewoon weet waar ik het over heb, en
> dat dat in twijfel wordt getrokken. Alsof ik de boel loop te bedotten.

Dit moet een uitspraak van Laurens zijn.

Lees dit goed: ik heb je mening en/of kennis nergens in twijfel getrokken, enkel
gevraagd om een goede uitleg. Dat je niet te klagen hebt over een gebrek aan
zelfverzekerdheid is vast geen nieuws, maar het is jammer dat je er slecht door
gaat luisteren/lezen en juist jij daardoor degene lijkt te worden die aan een
ander gaat twijfelen.

> > Dat een in code gebruikte curly apostrof (2019) op het scherm verschijnt als
> > een accent aigu zeg maar. Wel 'schuin' dus, maar zonder krul, en soms te
> > breed. Hetzelfde gebeurt op deze pagina (bv. het tabelletje in comment 150),
> > maar dat is wellicht normaal. Of toch niet?
> 
> Ok. Zeg dat dan. Dat ligt dan blijkbaar aan je OS, die een dergelijke
> ‘vertaling’ toepast, omdat een ‘ en ’ zich niet in de karakterset die hij
> gebruikt bevindt? Hier gebeurt dat niet in ieder geval.

Dat gaf ik aan in comment #134 en is idd precies wat ik bedoel.

> Het lijkt me in ieder geval ‘normaal’.

Zie je curly's op deze pagina?

> > > Aanhalingsteken is in Unicode teken U+2019 (8217 decimaal). Ik quote:
> > > 
> > > "2019 ’ RIGHT SINGLE QUOTATION MARK
> > > = SINGLE COMMA QUOTATION MARK
> > > - this is the preferred character to use for apostrophe"
> > 
> > Heb ik geloof ik destijds ook gepost.
> 
> Uh, ik weet niet meer wat jij gepost hebt, maar ik heb dat destijds opgezocht.

Prima, wij allebei dus. Ik doelde i.i.g. op het topic 'Verbeteringen..' (laatste
pagina). De aangehaalde link daarin pleit ook voor de 2019, maar helaas heeft
Anne nooit op het bericht geantwoord.

> > Je zal inmiddels begrijpen dat ik niet uit was op 'iets terugdraaien', noch op
> > een discussie daarover. Tenzij je doelt op het voorstel tot enkel op sommige
> > plaatsen toepassen van de curly's, maar dan is dat dus vanwege het
> > weergaveprobleem. Maar dat heeft wellicht een andere (of lokale) oorzaak,
> > waarmee dat voorstel uiteraard vervalt.
> 
> Wees dan wat duidelijker in je voorstel. Ik weet nu nog steeds niet wat je
> bedoelt. "enkel op sommige plaatsen toepassen van de curly's"? Wélke plaatsen
> dan? Maak er desnoods een aparte bug van.

Zie hierboven (2019 -> aigu). Lees, Laurens. Lees.


(In reply to comment #171)
> 
> *** Betreffende de karakterset/tekenset/whatever ***
> 
> (In reply to comment #164)
> > Zit wel wat in, maar dat geldt natuurlijk voor mensen die er aardig mee bekend
> > zijn. De doorsnee gebruiker ziet misschien vaker 'encoding' in (eerder
> > gebruikte) Engelse FF-versies en 'codering' in IE en krabt zich dan op zijn
> > hoofd.
> 
> Ja, en een gebruiker die in het Engels gewend is ‘link’ te zien weet ook niet
> wat koppeling betekent.

Beetje flauw om zo'n vergelijking te trekken en ook geen best voorbeeld. Mijn
punt is dat jouw uitleg over de geschiedenis van de term 'character set' vs.
'character encoding' niet bekend is bij de doorsnee gebruiker, en dus de term
'tekenset' meer vraagtekens op zou kunnen roepen dan 'codering'. Op het gebruik
van 'link' in het Nederlands zal ik verder maar niet ingaan.

> Of hij heeft eerder tekensetcodering gezien en weet niet
> wat dat betekent nu we dat gaan veranderen. Die doorsnee gebruiker weet toch
> niet genoeg van de materie om op een zinnige wijze iets met de tekenset te doen.

Het zal je misschien verbazen maar ik ben er steeds vanuit gegaan dat de
discussie over de term zowiezo een keer zou plaatsvinden en als
'tekensetcodering' wel juist zou zijn, dit erin zou blijven en anders simpelweg
en in 1 keer overal weer zou worden vervangen, precies zoals dat nu is gebeurd.
Als het wel de juiste term was dan zou ik me totaal niet druk maken over de
doorsnee gebruiker die de verandering vreemd vindt vanwege een tot dan toe
verkeerde of minder goede vertaling in een oudere versie, evenals bij iedere
andere wijziging. Maar daar hebben we het al eerder over gehad.

> Als je weet wat het is, dan weet je ook wat tekenset betekent. En dat het in het
> verleden of in andere talen anders is geweest betekent niet dat we niet voor de
> beste vertaling moeten gaan.

Uiteraard gaan we voor de beste vertaling, dat is het punt ook niet, en precies
wat ik hierboven bedoel.

> Ik zal kijken of ik vanavond op IRC kan zijn.

Ik ben er tegenwoordig wat minder, dus ook daar.

> > > Verder ben ik blijkbaar ook de enige die de materie begrijpt.
> > 
> > Ahum..
> 
> Nou, gezien de hoeveelheid uitleg die ik moet geven...

Nounou, beetje beleefdheid graag. Bovendien, en dat is wellicht handig om te
vermelden, vraag ik vaak om uitleg t.b.v. anderen, zowel vertalers als
geïnteresseerden die de bug alleen lezen. Het zal duidelijk zijn waarom.

> > > Het heeft niet specifiek met browsers te maken. Bovendien, het zijn niet
zomaar
> > > ‘meer resultaten’. Het zijn er zeventien duizend, tegenover een schamele
> > > tweehonderd.
> > 
> > Zie boven. :)
> 
> Kijk dan naar:
> 
> http://www.google.nl/search?q=karakterset
> 
> 11.200 resultaten. Daar zitten echt geen tekensetjes tussen.

Weet ik wel, maar ik dacht dat met tekenset ook vaak alleen maar de verzameling
tekens wordt bedoeld. Zonder de codes welteverstaan, vanwaar ook de voorkeur
voor 'tekencodering'.

> > Mooi gezegd. Had het eerder zo gedaan. ;)
> 
> No offense, maar ditzelfde heb ik op zijn minst al tien keer eerder gezegd.

Ahum..

> Behalve dat stukje over het type codering. Wat alleen als argument dient tegen
> het overnemen van de vertaling die Microsoft in IE gebruikt, wat nog niet eerder
> ter sprake was gekomen.

Wat ik zoals gezegd juist het belangrijkste vond en ook de verwarring vond geven
(zie comment #138). Echt fout is het immers niet. :)


    
    

    
  
(In reply to comment #194)
> (In reply to comment #169)
valentie
> (zie o.a. http://taalunieversum.org/taal/advies/tekst/9/). Zie het maar als
> 8-bit(s) 'brede' karakters. Zoiets ligt anders bij 24-uurseconomie.

Dankjewel voor de interessante link (koppeling?:-p), maar ik lees hem eerder als
een argument voor het aaneenschrijven.  Vooral het klemtoonargument:
8-bítskarakters, niet 8-bits karákters.
En valentie draai je om: het is een cursief 8-bitskarakter, niet een 8-bits
cursief karakter, tenminste, als je het mij vraagt.  Je kan ook niet spreken van
een zeer 8-bits karakter of een precies 8-bits karakter of zo.  Dat zou dan een
karakter van precies 8 bits moeten zijn (zonder streepje!).  Dat is overigens
ook al de hele reden dat er een streepje staat na de 8, om aan te geven dat het
een verbinding is.  Als je redeneert zoals jij, dan zou ook dat streepje weg
moeten, en dan ziet het er al helemaal niet meer uit.

> > > ["Platte-tekstberichten afbreken op">]
> dat Nederlanders spreken over "afbreken op [een bepaalde positie die ligt bij] x
> karakters". Je redenatie is dus niet verkeerd, alleen letterlijk en hier nu
> eenmaal niet zo gebruikelijk. 

Ik zeg ook `afbreken _op_ positie x', maar `_na_ karakter y' en dus `na x
karakters'.  Maar ik geef toe dat op even goed te verdedigen is.  

> Nooit opgevallen in andere programma's?

Nee, maar als dit idd zo is, dan leg ik me graag neer bij op (al zou ik dan
graag enkele voorbeelden zien/horen)

> wordt bedoeld. Maar wellicht is het toch beter. Vergeet alleen niet de access
key..

/me klopt zich op het hoofd.

    
    

    
  


  
Wederom 99.9% herschikkingen.

    
    

    
  


  
Reeksje kleinere wijzigingen ter opleuking.

    
    

    
  


  
De laatste hoop bestanden van mail bewerkt, kleinere wijzigingen.

Ook de readme voor OS/2 vertaald en verbeteringen aan deze zelfde voor Firefox.

    
    

    
  


  
Het eerste deel van deze patch, tot en met de eerste regels van pippki.dtd
bestaat uit wijzigingen, commentaar uiterst welkom. (helemaal in het begin gaat
het om een gewijzigde licentie)

Alles daaronder zijn enkel herschikkingen.

    
    

    
  


  
Sorry, de vorige patch was nog niet herschikt, hier gelden de bovenstaande
opmerkingen (vergeten opslaan)

        Attachment #198212 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 197402 [details] [diff] [review]
Enkele acces keys in messenger.dtd

Toegepast op branch en trunk.

Ik ga proberen nog wat patches toe te passen, maar vanaf maandagmiddag komt er
even een freeze wat betreft toepassen van patches. Op die manier kunnen we
zorgen dat er een vertaalde beta de deur uit gaat.

        Attachment #197402 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 197611 [details] [diff] [review]
Wederom, apostrofen patch

Toegepast op branch en trunk.

Er zaten nog wel wat hunks in, maar die heb ik handmatig opgelost.

        Attachment #197611 -
        Attachment is obsolete: true

    
    

    
  
Vanaf nu is er een lockdown voor nl wat betreft browserpatches tot beta2
verschenen is. De patch voor network/security check ik (of Tim Maks als hij
terug is) dan pas in op de branch. Ik ga even kijken of ik alle mailpatches nog
wel op zowel branch als trunk kan toepassen.

Zijn er trouwens mensen die mee willen helpen om beta2 intensief te testen op
Linux? Op het moment heb ik daar niet direct toegang toe. Ik plaats wel meer
informatie als die beschikbaar is.

    
    

    
  
(In reply to comment #204)
> Vanaf nu is er een lockdown voor nl wat betreft browserpatches tot beta2
> verschenen is. De patch voor network/security check ik (of Tim Maks als hij
> terug is) dan pas in op de branch. Ik ga even kijken of ik alle mailpatches nog
> wel op zowel branch als trunk kan toepassen.

Ik mag toch nog wel andere patches maken, hoop ik?  (hoewel ik het nu even druk
heb met verhuis, maar daarna)
 
> Zijn er trouwens mensen die mee willen helpen om beta2 intensief te testen op
> Linux? Op het moment heb ik daar niet direct toegang toe. Ik plaats wel meer
> informatie als die beschikbaar is.

Wat bedoel je met `intensief testen'?  Ik kan hem hier wel installeren en
gebruiken, maar echt tests doen zal ik niet...

    
    

    
  
(In reply to comment #205)
> (In reply to comment #204)
> > Vanaf nu is er een lockdown voor nl wat betreft browserpatches tot beta2
> > verschenen is. De patch voor network/security check ik (of Tim Maks als hij
> > terug is) dan pas in op de branch. Ik ga even kijken of ik alle mailpatches nog
> > wel op zowel branch als trunk kan toepassen.
> 
> Ik mag toch nog wel andere patches maken, hoop ik?  (hoewel ik het nu even druk
> heb met verhuis, maar daarna)
Tuurlijk mag dat, maar houdt er rekening mee dat er dus nog sommige patches
openstaan die wat hunks kunnen veroorzaken (zoals jouw laatste die dingen in
network en security verandert).

> > Zijn er trouwens mensen die mee willen helpen om beta2 intensief te testen op
> > Linux? Op het moment heb ik daar niet direct toegang toe. Ik plaats wel meer
> > informatie als die beschikbaar is.
> 
> Wat bedoel je met `intensief testen'?  Ik kan hem hier wel installeren en
> gebruiken, maar echt tests doen zal ik niet...
Zie ook http://wiki.mozilla.org/L10n:Firefox_1.5_beta_Status. Ik zal voor
Windows iig intensieve QA doen. Als jij gewoon met de versie werkt en even
verschillende dialoogvensters opent (Print(voorbeeld), pagina-instellingen,
opties, thema/extensie-beheerder etc.) en de installatiecontroleert dan is het
volgensmij ook goed.

    
    

    
  
Binnenkort moet de Nederlandse versie van 1.5beta2 vrijgegeven worden en daarmee
komen we steeds dichter bij de final. Voordat deze echter vrijgegeven wordt in
het Nederlands moet de hele vertaling gekeurd worden door Mozilla. Vooral wat
betreft bladwijzers en zoekplugins. Nadat de vertaling gecontroleerd is mag je
alleen wijzigingen toepassen die goedgekeurd zijn door Mozilla.
De truc is dus om dit niet te vroeg en niet te laat te doen. Mij lijkt eind
oktober een goede datum, omdat je dan in de buurt van RC1 zit.

Mijn vraag aan jullie is: welke dingen moeten er volgens jullie nog gewijzigd
worden en hoe lang zullen jullie hier mee bezig zijn?

Een aantal zaken die nog verbeterd moeten worden:
- Bij het afsluiten van het installatieprogramma op Windows verschijnt
'geïnstalleerd' op een rare manier (alsof niet de juiste codering gebruikt is).
Ik heb dit geprobeerd op te lossen in de trunk, maar dat is nog niet gelukt.
Misschien dat iemand hier naar kan kijken?
- Op de Mac zijn een aantal dialoogvensters te smal. Ik zal hier met de
mac-tester van de 1.5b2 rc's de juiste breedtes van de vensters zoeken.
- De help moet nog bijgewerkt worden, oa met verbeteringen die Hendrik had.

    
    

    
  


  
Enkele schoonheidswijzigingen aan het gemeenschappelijke deel van de help.

Deze patch had ik graag nog vσσr 1.5 ingecheckt gezien.

    
    

    
  


  
Dit zijn wederom enkel herschikkingen.	Een tweede patch voor de tweede helft
volgt nog.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Wijzigingen in toolkit - deel 1 (obsolete)
        — 
          — Splinter Review
      

    


  
De bijbehorende patch bij de herschikkingen, de wijzigingen.  Beoordeel zelf...


Deze beide patches kunnen gerust wachten tot na 1.5beta.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Wijzigingen in toolkit - deel 2 (obsolete)
        — 
          — Splinter Review
      

    


  
Nog meer kleine wijzigingen: spelfouten, vertaalfouten, onnodige backslashes...

    
    

    
  


  
Herschikkingen, deel 2

    
  
Depends on: 312423

    
    

    
  
Comment on attachment 197915 [details] [diff] [review]
Herschikkingen in mail/chrome/messenger

PAtch toegepast op Branch en Trunk.

Failed by:
Trunk: mail/chrome/messenger/messenger.dtd
mail/chrome/messenger/mime.properties
mail/chrome/messenger/msgSynchronize.dtd
mail/chrome/messenger/preferences/compose.dtd
mail/chrome/messenger/preferences/privacy.dtd
mail/chrome/messenger/preferences/sendoptions.dtd

Branch:
mail/chrome/messenger/aboutDialog.dtd
mail/chrome/messenger/am-addressing.dtd
mail/chrome/messenger/am-server-top.dtd
mail/chrome/messenger/custom.properties
mail/chrome/messenger/imapMsgs.properties
mail/chrome/messenger/importDialog.dtd
mail/chrome/messenger/localMsgs.properties
mail/chrome/messenger/messenger.dtd
mail/chrome/messenger/mime.properties
mail/chrome/messenger/msgSynchronize.dtd
mail/chrome/messenger/preferences/compose.dtd
mail/chrome/messenger/preferences/privacy.dtd
mail/chrome/messenger/preferences/sendoptions.dtd

        Attachment #197915 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 197916 [details] [diff] [review]
aparte patch voor msgs.properties

Patch is niet toegepast vanwege een hunk

        Attachment #197916 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 197921 [details] [diff] [review]
Wijzigingen in messenger

niet toegepast, een groote hunk

        Attachment #197921 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #215)
> (From update of attachment 197921 [details] [diff] [review] [edit])
> niet toegepast, een groote hunk
> 

een aantal van de wijziging zijn blijkbaar al toegepast.

    
    

    
  
Comment on attachment 198128 [details] [diff] [review]
Herschikkingen in mail/chrome/, alfabetisch na messenger

patch toegepast op branch en trunk

        Attachment #198128 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 198129 [details] [diff] [review]
Wijzigingen in mail/chrome, na messenger

toegepast op branch en trunk

        Attachment #198129 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 198146 [details] [diff] [review]
Laatste verbeteringen voor mail, readmes

patch toegepast op branch en trunk (controleer de readme.txt nog even, er kwam
een malformed melding langs)

        Attachment #198146 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 198213 [details] [diff] [review]
correctie: dit is network en security

Patch toegepast op branch en trunk.
hunk:
security/manager/chrome/pipnss/pipnss.properties

        Attachment #198213 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 198923 [details] [diff] [review]
verbeterd het scherm `help gebruiken'

patch toegepast op branch en trunk

        Attachment #198923 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 198924 [details] [diff] [review]
Herschikkingen in toolkit - deel 1

toegepast branch en trunk.

hunk:
toolkit/chrome/global/tabbrowser.properties
toolkit/chrome/global/history/history.properties

        Attachment #198924 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #210)
> Created an attachment (id=198925) [edit]
> Wijzigingen in toolkit - deel 1
> 
> De bijbehorende patch bij de herschikkingen, de wijzigingen.  Beoordeel zelf...
> 
> 
> Deze beide patches kunnen gerust wachten tot na 1.5beta.

Voor de laaste keer: Maak je patches kleiner, beperk het tot een paar bestanden
in een keer!

-<!ENTITY headerLeft.tip      "Linker koptekst">
+<!ENTITY headerLeft.tip      "Linkse koptekst">
 <!ENTITY headerCenter.tip    "Middelste koptekst">
-<!ENTITY headerRight.tip     "Rechter koptekst">
-<!ENTITY footerLeft.tip      "Linker voettekst">
+<!ENTITY headerRight.tip     "Rechtse koptekst">
+<!ENTITY footerLeft.tip      "Linkse voettekst">
 <!ENTITY footerCenter.tip    "Middelste voettekst">
-<!ENTITY footerRight.tip     "Rechter voettekst">
+<!ENTITY footerRight.tip     "Rechtse voettekst">
 
ik weet niet zeker of dit een juiste verandering is en daarom pas ik de gehele
patch niet toe



    
    

    
  
Comment on attachment 198957 [details] [diff] [review]
Wijzigingen in toolkit - deel 2

Toegepast op branch en trunk

hunk:
toolkit/chrome/mozapps/update/update.properties

        Attachment #198957 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 198958 [details] [diff] [review]
Herschikkingen in toolkit - deel 2

toegepast op branch en trunk

hunk:
toolkit/chrome/mozapps/profile/createProfileWizard.dtd
toolkit/chrome/mozapps/update/errors.dtd

    
  

        Attachment #198958 -
        Attachment is obsolete: true

    
    

    
  
Alle open staande patches zijn nu toegepast (behalve attachment 198925 [details] [diff] [review] ), graag
een controle.

Nu we richting versie 1.5 RC1 gaan wil ik vanaf nu alleen nog maar
taalverberingen toepassen en geen herschikkingen (dit kan weer na de release van
1.5).

maak de patches ook niet te groot zodat het overzichtelijk blijft en als er iets
fout mee gaat niet meteen een hoop wijzigingen niet doorgevoerd worden.

Allen bedankt voor het vele werk!!

Tim Maks

    
    

    
  
(In reply to comment #223)
> (In reply to comment #210)

> Voor de laaste keer: Maak je patches kleiner, beperk het tot een paar bestanden
> in een keer!

Hm, ik probeer de lengte van deze bug een beetje te beperken :-p  Nee ok.
 
> -<!ENTITY headerLeft.tip      "Linker koptekst">
> +<!ENTITY headerLeft.tip      "Linkse koptekst">
> ik weet niet zeker of dit een juiste verandering is en daarom pas ik de gehele
> patch niet toe

Je mag het er niet mee eens zijn, maar wat er nu staat is zeker fout: linker- en
rechter- moeten *steeds* aan een woord vastgeschreven worden.  Het is dus ofwel
Linkerkoptekst of Linkse koptekst.  Dan vind ik het laatste overzichtelijker.

(In reply to comment #226)
> Nu we richting versie 1.5 RC1 gaan wil ik vanaf nu alleen nog maar
> taalverberingen toepassen en geen herschikkingen (dit kan weer na de release van
> 1.5).

Maar mag ik nog die paar patches die mislukt zijn opnieuw maken?  Anders nogal
zonde van het werk dat ik hier al in gestoken heb.  Het betreft dus
herschikkingen in mail en toolkit.

> Allen bedankt voor het vele werk!!

My pleasure.

    
    

    
  
(In reply to comment #226)
> Alle open staande patches zijn nu toegepast (behalve attachment 198925 [details] [diff] [review] [edit]
), graag
> een controle.

Als er dan toch een controle komt: ik ben niet zeker van 
toolkit/chrome/global/intl.properties
-general.useragent.locale=nl-NL
+general.useragent.locale=nl

Kan iemand mij hierin eens opklaring geven?

    
    

    
  


  
Dit is de oplossing voor de hunks die in de vorige patches optraden.  Dit zijn
weer enkel herschikkingen, op zich kan dit wachten tot na 1.5, maar dat zou
betekenen dat ik constant conflicten krijg...

    
    

    
  


  
Dit is de patch die nog niet is toegepast, maar opnieuw, met de conflicten
ontstaan door het toepassen van al de andere opgelost.

        Attachment #198925 -
        Attachment is obsolete: true

    
    

    
  


  
Dit zijn dezelfde als voorheen, maar met de conflicten en hunks opgelost.
(Lijkt enorm, maar het gaat maar om 12 bestanden hoor)

    
    

    
  


  
Nog enkele opgeloste hunks.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        En de overige hunks (obsolete)
        — 
          — Splinter Review
      

    


  
Nog een paar dingen die hunks opleverden (of zijn het nieuwe wijzigingen, hm,
ben beetje de kluts kwijt).

Dit is echt alles wat ik lokaal heb nu, dus ik zal jullie voorlopig niet meer
lastigvallen tot 1.5b uit is :-)

    
    

    
  
(In reply to comment #219)
> (From update of attachment 198146 [details] [diff] [review] [edit])
> patch toegepast op branch en trunk (controleer de readme.txt nog even, er kwam
> een malformed melding langs)

Hm, ik weet niet goed wat er aan de hand is.  Bij een compare geeft Eclipse mij
een BOM aan het begin van de remote file en zijn alle trema's in ¥× o.i.d.
veranderd, maar als ik vraag om een patch, dan zegt hij dat er geen wijzigingen
gevonden zijn.  Misschien heeft het bestand in CVS een verkeerd MIME-type?

    
    

    
  
(In reply to comment #227)
  
> > -<!ENTITY headerLeft.tip      "Linker koptekst">
> > +<!ENTITY headerLeft.tip      "Linkse koptekst">
> > ik weet niet zeker of dit een juiste verandering is en daarom pas ik de gehele
> > patch niet toe
> 
> Je mag het er niet mee eens zijn, maar wat er nu staat is zeker fout: linker- en
> rechter- moeten *steeds* aan een woord vastgeschreven worden.  Het is dus ofwel
> Linkerkoptekst of Linkse koptekst.  Dan vind ik het laatste overzichtelijker.
> 
kan iemand anders dit bevestigen, het gaat er niet om wat ik denk maar wat goed
is ;-)


> (In reply to comment #226)
> > Nu we richting versie 1.5 RC1 gaan wil ik vanaf nu alleen nog maar
> > taalverberingen toepassen en geen herschikkingen (dit kan weer na de release van
> > 1.5).
> 
> Maar mag ik nog die paar patches die mislukt zijn opnieuw maken?  Anders nogal
> zonde van het werk dat ik hier al in gestoken heb.  Het betreft dus
> herschikkingen in mail en toolkit.

Ja maar natuurlijk

    
    

    
  
Comment on attachment 199671 [details] [diff] [review]
Opnieuw: herschikkingen in toolkit

toegepast op branch en trunk

        Attachment #199671 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 199673 [details] [diff] [review]
Herschikkingen in mail, conflicten opgelost

Toegepast op branch en trunk

hunks in de trunk:
mail/chrome/messenger/imapMsgs.properties
mail/chrome/messenger/importDialog.dtd

        Attachment #199673 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 199674 [details] [diff] [review]
nog enkele kleine wijzigingen in mail na conflictoplossing

toegepast op trunk en branch

hunk:
mail/chrome/messenger/searchTermOverlay.dtd

        Attachment #199674 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 199675 [details] [diff] [review]
En de overige hunks

toegepast op branch en trunk

        Attachment #199675 -
        Attachment is obsolete: true

    
    

    
  
Vandaag bij het test gebruik van Fx beta 2 zag ik dat bij het vragen naar een
wachtwoord het dialoogvenster als titel "vragen" heeft, wat erg raar overkomt.

In het engels is het "promt", kunnen we dat niet anders vertalen?
http://lxr.mozilla.org/l10n/source/nl/toolkit/chrome/global/commonDialogs.properties

    
    

    
  
(In reply to comment #235)
> (In reply to comment #227)
>   
> > > -<!ENTITY headerLeft.tip      "Linker koptekst">
> > > +<!ENTITY headerLeft.tip      "Linkse koptekst">
> > > ik weet niet zeker of dit een juiste verandering is en daarom pas ik de gehele
> > > patch niet toe
> > 
> > Je mag het er niet mee eens zijn, maar wat er nu staat is zeker fout: linker- en
> > rechter- moeten *steeds* aan een woord vastgeschreven worden.  Het is dus ofwel
> > Linkerkoptekst of Linkse koptekst.  Dan vind ik het laatste overzichtelijker.
> > 
> kan iemand anders dit bevestigen, het gaat er niet om wat ik denk maar wat goed
> is ;-)

Linker en rechter los lijkt mij inderdaad gewoon in orde. Alleen bij
ingeburgerde woorden worden deze termen aaneengeschreven en dat kunnen we niet
zeggen van kop- en voetteksten.

Overigens voel ik wel iets voor een soort 'lock' of 'final approval' op
bestanden. Dit vanwege een correctievoorstel als hierboven, en andere zaken die
al eerder zijn besproken en afgewezen, zoals bijv. state.header in history.dtd,
att. 198957, die vervolgens waarschijnlijk door vergeten opnieuw worden
voorgesteld en alsnog worden uitgevoerd. Misschien niet echt handig met een nog
veranderende source, maar wel mogelijk in deze fase? :-/

TM: Kan je nog even antwoorden op comment #74 (het 'bladwijzer voor-probleem')
en dit als het geen probleem wordt gevonden terugzetten? Wat is nu precies het
probleem met de breedte, en kan het worden opgelost door een puntje minder?

Hendrik: zou je de helpbestanden nog willen doorlopen op rood/groen, zoals
toegezegd, of sta je mij toe..? En w.b. 8-bittekens en 8-bits-ascii-karakters
e.d.: ik zou toch graag i.i.g. bits (met s) zien (en consistent), en ook los.
Niet alles is immers een samenstelling, woordgroepen zijn zeldzamer maar hebben
ook bestaansrecht. :) Ook zag ik hier en daar nog wat andere volgens mij Vlaamse
voorkeuren die op zijn minst twijfelachtig zijn te noemen, dan wel onnodig,
zoals vanwege->wegens etc. (Sorry..) Maar vergeet dat maar even.


    
    

    
  
(In reply to comment #240)
> 
> In het engels is het "promt", kunnen we dat niet anders vertalen?
>
http://lxr.mozilla.org/l10n/source/nl/toolkit/chrome/global/commonDialogs.properties

Inderdaad twijfelachtig. Wat te denken van 'invoer', in alledrie de gevallen?

    
    

    
  


  
Verloren gegane wijzigingen door herschikkingen.

    
    

    
  
(In reply to comment #240)
> Vandaag bij het test gebruik van Fx beta 2 zag ik dat bij het vragen naar een
> wachtwoord het dialoogvenster als titel "vragen" heeft, wat erg raar overkomt.
> 
> In het engels is het "promt", kunnen we dat niet anders vertalen?
>
http://lxr.mozilla.org/l10n/source/nl/toolkit/chrome/global/commonDialogs.properties

http://vertaling.vrijschrift.nl/woordenboek geeft als andere vertaling Vraag of
gewoon Prompt. Vraag geeft wel goed aan wat de bedoeling is van het
dialoogvenster. Prompt kan ook, maar is misschien iets vager voor de gebruiker.

Invoer zoals Ton aandroeg is ook wel goed, maar ik vind Vraag net was specifieker.

(In reply to comment #241)
> Overigens voel ik wel iets voor een soort 'lock' of 'final approval' op
> bestanden. Dit vanwege een correctievoorstel als hierboven, en andere zaken die
> al eerder zijn besproken en afgewezen, zoals bijv. state.header in history.dtd,
> att. 198957, die vervolgens waarschijnlijk door vergeten opnieuw worden
> voorgesteld en alsnog worden uitgevoerd. Misschien niet echt handig met een nog
> veranderende source, maar wel mogelijk in deze fase? :-/
Een lock op 1 bestand is volgensmij niet mogelijk. Voor dingen waar vaak
problemen mee zijn is er de woordenlijst en verder is het misschien goed dat
iedereen ook een beetje bijhoudt wat er verandert. Als het een keer verkeerd
veranderd wordt is een vermelding in het woordenboek misschien een optie.
> TM: Kan je nog even antwoorden op comment #74 (het 'bladwijzer voor-probleem')
> en dit als het geen probleem wordt gevonden terugzetten? Wat is nu precies het
> probleem met de breedte, en kan het worden opgelost door een puntje minder?
Een puntje minder is geen oplossing, maar ondertussen heb ik een oplossing
gevonden om het menu breder te maken. Wat mij betreft kan voor dan wel terug,
want ik snap je redenering nu. Voor past dan idd beter. Misschien kun je een
patch maken die het terugzet, dan zorg ik er binnenkort voor dat het menu breed
genoeg is met het woord voor erin (in Win XP iig).

    
    

    
  
(In reply to comment #241)
> (In reply to comment #235)
> > (In reply to comment #227)
> Linker en rechter los lijkt mij inderdaad gewoon in orde. Alleen bij
> ingeburgerde woorden worden deze termen aaneengeschreven en dat kunnen we niet
> zeggen van kop- en voetteksten.

In het woordenboek gekeken?
Elektronische Van Dale:
	linker
lin•ker
 /l’imkfr/
de (m.)
		1	Ÿ	(verouderd) bedrieger, schelm, valsaard
		2	Ÿ	vent, kerel
		3	Ÿ	linkerd (zie aldaar)

linker-
lin•ker-
 /l’imkfr/
		1	Ÿ	als eerste lid in samengestelde zn. ter aanduiding dat het in het tweede
lid genoemde zich links bevindt (soms ook als attributief bn. gebruikt, maar dan
altijd onverbogen)
antoniem: rechter-
		 				linkerachterlicht, linkerachterpoot, linkerader, linkerarm, linkerbeen,
linkerbenedenhoek, linkerbeuk, linkerbil,...

Let op het streepje.  Het is niet omdat het hier wat langer wordt dat daar plots
een spatie op zijn plaats is, zie ook lemmata als linkerbovenhoek enz.

Analoog voor rechter (= persoon in gerecht en loopplank) vs. rechter-

Ik geef toe dat linker en rechter ook als bn gebruikt worden (volgens
nederlandsewoorden.nl en ook hierboven), maar vind het hier onnozel uitzien.

> Hendrik: zou je de helpbestanden nog willen doorlopen op rood/groen, zoals
> toegezegd, of sta je mij toe..? 

Tuurlijk, ik moet er toch nog iedere keer over nadenken welke nu ook weer de
juiste volgorde was, dan is het makkelijker als jij dat doet.  Vergeet niet het
gedeelte in toolkit.

> En w.b. 8-bittekens en 8-bits-ascii-karakters
> e.d.: ik zou toch graag i.i.g. bits (met s) zien (en consistent), en ook los.
> Niet alles is immers een samenstelling, woordgroepen zijn zeldzamer maar hebben
> ook bestaansrecht. :) 

En ik zou die graag aan elkaar zien.  Is dat een goed argument?  Ik denk dat ik
zeer overtuigende argumenten heb aangedragen om dit aan elkaar te schrijven.  De
s is zeker op zijn plaats, alleen het aantal streepjes is w.m.b nog discutabel.

Ben ook wel te vinden voor een lock als dat nodig is, maar liefst zo lang
mogelijk uitstellen.
(In reply to comment #244)
> (In reply to comment #240)
> > In het engels is het "prompt", kunnen we dat niet anders vertalen?
> http://vertaling.vrijschrift.nl/woordenboek geeft als andere vertaling Vraag of
> gewoon Prompt. Vraag geeft wel goed aan wat de bedoeling is van het
> dialoogvenster. Prompt kan ook, maar is misschien iets vager voor de gebruiker.

Gniffel gniffel, ik moet toch even bekennen dat ik ‘Vraag’ daar zelf deze
ochtend bijgezet heb.  Ik vind het ook het beste alternatief, maar het is m.i.
gewoon stom om een venster zo'n betekenisloze titel te geven.  Misschien maak ik
hier eens een bugje van.

    
    

    
  
(In reply to comment #245)
> 
> Ik geef toe dat linker en rechter ook als bn gebruikt worden (volgens
> nederlandsewoorden.nl en ook hierboven), maar vind het hier onnozel uitzien.

Linker is inderdaad, maar als je het mij vraagt in de eerste instantie een
bijvoeglijk naamwoord, en http://www.onzetaal.nl/advies/linker.html geeft aan
dat minder voorkomende woordgroepen het daarom (nog?) losstaand gebruiken. Voor
mij duidelijk genoeg en ook zeer gebruikelijk, althans in NL. Verder is er
onnozel uitzien meestal niet zo'n goed argument geweest voor spelling, maar als
je het daarop wilt gooien: ik heb zo mijn twijfels over of een linkerkoptekst
nou een tekst op een linkerkop is of niet.

> En ik zou die graag aan elkaar zien.  Is dat een goed argument?  Ik denk dat ik
> zeer overtuigende argumenten heb aangedragen om dit aan elkaar te schrijven.  De
> s is zeker op zijn plaats, alleen het aantal streepjes is w.m.b nog discutabel.

De s duidt op een b.n., en is des te meer een reden om ze los te schrijven;
zonder s ligt dat minder voor de hand. In termen als '128-bits RC4-versleuteling
met RSA..' is het b.n.-aspect duidelijker te zien. Bij een '8-bits karakter' is
het weliswaar verleidelijk om dit als 1 z.n. te gaan zien maar zeker niet de
regel, ook niet volgens jouw argumenten. De termen zijn te uniek om er een
samenstelling van te maken en misschien het beste te vergelijken met termen
waarvoor 'standaard' (los) wordt gebruikt. Maar zelfs als zowel '8-bits
karakters' als '8-bitkarakters' als goed kunnen worden beoordeeld geef ik voor
de vertaling toch de voorkeur voor het eerste, simpelweg vanwege leesbaarheid,
gangbaarheid en daarmee het begrip bij de gebruiker. Overigens zul je via Google
geen resultaten vinden met '-bit(s)teken' o.i.d. erin dus ik blijf vermoeden dat
'8-bittekens' en/of karakters gewoon echt fout is.

> Ben ook wel te vinden voor een lock als dat nodig is, maar liefst zo lang
> mogelijk uitstellen.

Ik weet niet of het dan nog veel zin heeft, maar het helpt wel iets.

> (In reply to comment #244)
> > (In reply to comment #240)
> > > In het engels is het "prompt", kunnen we dat niet anders vertalen?
> > http://vertaling.vrijschrift.nl/woordenboek geeft als andere vertaling Vraag of
> > gewoon Prompt. Vraag geeft wel goed aan wat de bedoeling is van het
> > dialoogvenster. Prompt kan ook, maar is misschien iets vager voor de gebruiker.
> 
> Gniffel gniffel, ik moet toch even bekennen dat ik ‘Vraag’ daar zelf deze
> ochtend bijgezet heb.  Ik vind het ook het beste alternatief, maar het is m.i.
> gewoon stom om een venster zo'n betekenisloze titel te geven.  Misschien maak ik
> hier eens een bugje van.

Vraag kan ook, maar dan prefereer ik toch Invoer, aangezien de gebruikeractie er
wat meer in zit opgesloten. Dat het een vraag betreft is allang duidelijk, want
daar is immers elk vragend dialoogvenster voor. De in te voeren tekst bepaalt
dan het verschil tussen bijv. Ja/Nee klikken en het invoeren van de string, en
dus tussen een Vraag en een Invoer.

    
    

    
  
(In reply to comment #246)
> (In reply to comment #245)
> je het daarop wilt gooien: ik heb zo mijn twijfels over of een linkerkoptekst
> nou een tekst op een linkerkop is of niet.

Vandaar mijn voorstel om er linkse koptekst van te maken.

> > En ik zou die graag aan elkaar zien.  Is dat een goed argument?  Ik denk dat ik
> > zeer overtuigende argumenten heb aangedragen om dit aan elkaar te schrijven.  De
> > s is zeker op zijn plaats, alleen het aantal streepjes is w.m.b nog discutabel.
> 
> De s duidt op een b.n., en is des te meer een reden om ze los te schrijven;

8-bits is geen bijvoeglijk naamwoord.

    
    

    
  
(In reply to comment #247)

> Vandaar mijn voorstel om er linkse koptekst van te maken.

Jammer dus dat je om een dergelijke reden moet uitwijken.

> 8-bits is geen bijvoeglijk naamwoord.

Je meent het..


    
    

    
  
Comment on attachment 195888 [details] [diff] [review]
Bladwijzer voor => Bladwijzer van

Deze patch is teruggedraaid in branch en trunk

van te maken = > voor te maken

    
    

    
  
(In reply to comment #220)
> (From update of attachment 198213 [details] [diff] [review] [edit])
> Patch toegepast op branch en trunk.
> hunk:
> security/manager/chrome/pipnss/pipnss.properties
> 

Wat mij betreft wordt deze in zijn geheel teruggedraaid, gezien het aantal
fouten c.q. twijfelachtige zaken.

    
    

    
  
(In reply to comment #195)
> > Het lijkt me in ieder geval ‘normaal’.
> 
> Zie je curly's op deze pagina?

Yep.


~Grauw

    
    

    
  


  
Startpagina gebruiken voor startpagina’s (bijv. start.mozilla.org/firefox), en
homepage gebruiken voor homepages (bijv. www.mozilla.org, of
extensie-homepages).

Voor degenen die niet overtuigd zijn dat we hier homepage kunnen gebruiken,
zie:
http://www.onzetaal.nl/advies/website.html

In het kort, ik vind dat startpagina geen goede vertaling is van homepage, mijn
homepage www.grauw.nl is geen startpagina. Het klinkt mij elke keer vreemd in
de oren wanneer het als zodanig wordt gebruikt, in het bijzonder in de
extensiemanager. Een meer Nederlandse vertaling van homepage ben ik niet mee
bekend, en homepage mag van onzetaal, dus... zodoende.


~Grauw

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Paar verspreide correcties (obsolete)
        — 
          — Splinter Review
      

    


  
Deze patch bevat de volgende wijzigingen:

-<!ENTITY  pageColorHeader	     "Standaard pagina-uitzicht">
+<!ENTITY  pageColorHeader	     "Standaard pagina-presentatie">

Uitzicht is vreemd, na discussie was er geen verder bezwaar tegen presentatie.


-<!ENTITY wrapOutMsg.label		       "Platte-tekstberichten afbreken
na">
+<!ENTITY wrapOutMsg.label		       "Platte-tekstberichten afbreken
op">

Deze is veranderd alhoewel er bezwaar tegen was, en degeen die het veranderde
ook toegaf dat op niet fout is. Dus dit verandert het terug.


-<!ENTITY prefColumn.label "Voorkeursnaam">
+<!ENTITY prefColumn.label "Voorkeurnaam">

Het is de naam van een voorkeur, niet een naam die iemand ergens bij voorkeur
aan geeft.


-<!ENTITY launch "Start bestand">
+<!ENTITY launch "Bestand openen">

Dit was fout.


~Grauw

    
    

    
  
(In reply to comment #252)
> Created an attachment (id=199969) [edit]
> Startpagina -> homepage, waar van toepassing

Mij best, maar hier:

-<!ENTITY enableStartPage.label            "Wanneer &brandShortName; start, de
startpagina in het berichtgedeelte tonen">
+<!ENTITY enableStartPage.label            "Wanneer &brandShortName; start, de
homepage in het berichtgedeelte tonen">

Zou ik het toch op startpagina houden.   Het gaat hier tenslotte om welcome.html
in TB, wat bezwaarlijk een homepage kan genoemd worden.

    
    

    
  


  
(In reply to comment #254)
> Mij best, maar hier:
> 
> -<!ENTITY enableStartPage.label	     "Wanneer &brandShortName; start,
de
> startpagina in het berichtgedeelte tonen">
> +<!ENTITY enableStartPage.label	     "Wanneer &brandShortName; start,
de
> homepage in het berichtgedeelte tonen">
> 
> Zou ik het toch op startpagina houden.   Het gaat hier tenslotte om
> welcome.html in TB, wat bezwaarlijk een homepage kan genoemd worden.

Je hebt helemaal gelijk. Nieuwe patch.


~Grauw

        Attachment #199969 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #255)
> Created an attachment (id=200064) [edit]
> Startpagina -> homepage, waar van toepassing (nieuw)
> > 
> > Zou ik het toch op startpagina houden.   Het gaat hier tenslotte om
> > welcome.html in TB, wat bezwaarlijk een homepage kan genoemd worden.
> 
> Je hebt helemaal gelijk. Nieuwe patch.

Homepage OK, maar liever zonder koppelteken. Het gaat hier om woordgroepen, geen
samenstellingen (argument: klemtoon).

    
    

    
  
Comment on attachment 199970 [details] [diff] [review]
Paar verspreide correcties

Toegepast op branch en trunk.

        Attachment #199970 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 199757 [details] [diff] [review]
Enkele access keys in messenger.dtd (2)

Toegepast op branch en trunk.

        Attachment #199757 -
        Attachment is obsolete: true

    
    

    
  


  
Wat verbeteringen die ik zometeen wil toepassen. Het zijn heel kleine dingen
qua gebruik van de infinitief.

    
    

    
  
Comment on attachment 200121 [details] [diff] [review]
Verbeteringen van infinitief vormen

Toegepast op branch en trunk.

        Attachment #200121 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #256)
> Homepage OK, maar liever zonder koppelteken. Het gaat hier om woordgroepen,
> geen samenstellingen (argument: klemtoon).

Ik snap niet echt wat je bedoelt.

"Ga naar de Firefox-homepage", dat is volgens mij correct.

"Ga naar de Firefoxhomepage" lijkt me onzinnig, dat impliceert dat er een
speciaal type homepage is, te weten van het type Firefox.

"Ga naar de Firefox homepage" vind ik vreemd, dan krijgen Firefox en homepage
ongeveer evenveel klemtoon (met een kleine pauze ertussen), terwijl bij de
eerste Firefox meer nadruk dan homepage krijgt, en zo spreek ik het ook uit.

Ik ben geen expert op het gebied van spellingsregels, maar de alternatieven
zonder koppelstreepje komen vreemd op mij over.

Kan zonodig Hendrik een second opinion geven?


~Grauw

    
    

    
  
(In reply to comment #261)
> (In reply to comment #256)
> > Homepage OK, maar liever zonder koppelteken. Het gaat hier om woordgroepen,
> > geen samenstellingen (argument: klemtoon).
> 
> Ik snap niet echt wat je bedoelt.

Ton is nogal voorstander van het begrip `woordgroep', maar ik vrees dat hij zich
daarbij wat te veel door het Engels laat beïnvloeden, waar je een onbegrensd
aantal naamwoorden naast elkaar kan zetten die dan idd een woordgroep vormen. 
In het Nederlands kan dit niet.
 
> "Ga naar de Firefox-homepage", dat is volgens mij correct.

Ja. 
 
> "Ga naar de Firefoxhomepage" lijkt me onzinnig, dat impliceert dat er een
> speciaal type homepage is, te weten van het type Firefox.

Je gevolgtrekking deel ik niet helemaal, semantisch gezien betekent het
hetzelfde als de vorige, het streepje is dan zogezegd een streepje `ter
verduidelijking' (zoals die hier nogal vaak gebruikt worden waar ik ze niet
nodig vind, maar soit).  Het is in dit geval echter gebruikelijk om een streepje
te zetten, aangezien het eerste deel een eigennaam is.  Een oplossing waar
niemand iets op aan te merken kan hebben is natuurlijk `de homepage van
Firefox', behalve dan dat het vier tekens langer is.  Ah, jammer dat we geen
genitief meer hebben in het Nl :-p
 
> "Ga naar de Firefox homepage" vind ik vreemd, dan krijgen Firefox en homepage
> ongeveer evenveel klemtoon (met een kleine pauze ertussen), terwijl bij de
> eerste Firefox meer nadruk dan homepage krijgt, en zo spreek ik het ook uit.

Inderdaad.  Dat is de reden waarom het m.i. geen woordgroep is, maar zoals in de
discussie over 8-bits al gebleken is daar geen eensgezindheid over.  Nog maar
eens een vraag aan de taaladviesdienst dan maar?

> Ik ben geen expert op het gebied van spellingsregels, maar de alternatieven
> zonder koppelstreepje komen vreemd op mij over.

Op mij ook.

> Kan zonodig Hendrik een second opinion geven?

Graag.

    
    

    
  
(In reply to comment #261)
> (In reply to comment #256)
> > Homepage OK, maar liever zonder koppelteken. Het gaat hier om woordgroepen,
> > geen samenstellingen (argument: klemtoon).
> 
> Ik snap niet echt wat je bedoelt.

Ok, ik had erbij moeten zeggen 'mét spatie'.

> "Ga naar de Firefox-homepage", dat is volgens mij correct.

Het zou juist zijn als men spreekt over één van meerdere homepages. Ofwel,
'Firefox' is hierboven een typeaanduiding bij homepage en te bepalend.

> "Ga naar de Firefoxhomepage" lijkt me onzinnig, dat impliceert dat er een
> speciaal type homepage is, te weten van het type Firefox.

Yep, uitgesloten en zelfs verboden vermoed ik (eigennaam/merknaam).

> "Ga naar de Firefox homepage" vind ik vreemd, dan krijgen Firefox en homepage
> ongeveer evenveel klemtoon (met een kleine pauze ertussen),

Precies, de spatie maakt dat de klemtoon zelfs iets meer op het laatste deel
ligt, en dat is toch wat we willen?

> terwijl bij de
> eerste Firefox meer nadruk dan homepage krijgt, en zo spreek ik het ook uit.

Dan rijst automatisch de vraag "welke zijn er dan nog meer?" De bewuste knoppen
rechtsboven verwijzen naar mijn idee naar de TB hómepage, zijnde een zogenaamd
gelinkt onderdeel van het programma, te vinden op de Mozilla-website (niet te
verwarren met de startpagina-instelling in TB, wat weer wel een samenstelling is).

> Ik ben geen expert op het gebied van spellingsregels, maar de alternatieven
> zonder koppelstreepje komen vreemd op mij over.

Het is hetzelfde als de Thunderbird prodúctpagina (in berichtvenster) of de AH
Hámsterweken. Firefox- en Mozilla-koppelingen (in bladwijzers) zijn wel
samenstellingen, dus bepaalde koppelingen tussen een aantal andere.

Deze strings moeten in Firefox trouwens ook nog worden gewijzigd.

> Kan zonodig Hendrik een second opinion geven?

Graag.



    
    

    
  
(In reply to comment #263)
> (In reply to comment #261)
> > (In reply to comment #256)
> > > Homepage OK, maar liever zonder koppelteken. Het gaat hier om woordgroepen,
> > > geen samenstellingen (argument: klemtoon).

Dit klemtoonargument schijnt dus niet sterk te zijn, daar iedereen de klemtoon
elders schijnt te leggen.  Bij mij is er maar één klemtoon, op de i van Firefox.

> > "Ga naar de Firefox-homepage", dat is volgens mij correct.
> 
> Het zou juist zijn als men spreekt over één van meerdere homepages. Ofwel,
> 'Firefox' is hierboven een typeaanduiding bij homepage en te bepalend.

> > "Ga naar de Firefox homepage" vind ik vreemd, dan krijgen Firefox en homepage
> > ongeveer evenveel klemtoon (met een kleine pauze ertussen),
> 
> Precies, de spatie maakt dat de klemtoon zelfs iets meer op het laatste deel
> ligt, en dat is toch wat we willen?

Waarom zouden we dat willen? 

> Het is hetzelfde als de Thunderbird prodúctpagina (in berichtvenster) of de AH
> Hámsterweken. Firefox- en Mozilla-koppelingen (in bladwijzers) zijn wel
> samenstellingen, dus bepaalde koppelingen tussen een aantal andere.

Ik snap echt niet waar je naartoe wilt.  Er zijn toch miljoenen homepages?  En
wij verwijzen naar die van Firefox, naar de Firefox-homepage dus.  (Of de
Mozilla-homepage, want er staat ook ergens &vendorShortName;, waar ik al
helemaal de neiging krijg om `homepage van Mozilla' te schrijven.)

Het onderscheid dat jij maakt bestaat niet naar mijn taalgevoel.  Ook al doet AH
er wel aan, volgens mij is het een rechtstreekse invloed uit het Engels.  Je zou
me kunnen overtuigen met voorbeelden van woordgroepen in deze stijl die niet
door één of ander bedrijf zelf bedacht zijn, maar die gebruikelijk zijn.  Iets
als hogesnelheidstrein dus, maar dan het tegenvoorbeeld.

(Overigens moet deze koppeling voor FF nog ergens aangepast worden, ze verwijst
nog naar de Engelse versie.)

    
    

    
  
(In reply to comment #259)
> Created an attachment (id=200121) [edit]
> Verbeteringen van infinitief vormen
> 
> Wat verbeteringen die ik zometeen wil toepassen. Het zijn heel kleine dingen
> qua gebruik van de infinitief.

Ik zet eigenlijk alleen wat vraagtekens bij de labelwijzigingen in
msgFolderPickerOverlay.dtd. Meen me te herinneren dat i.i.g. de kleine letters
belangrijk waren, en zo even snel wat strings bekijkend geloof ik dat de oude
werkwoordsvormen ook wat beter stonden dan infinitieven. Kan je/iemand hier nog
even naar kijken?

    
    

    
  
(In reply to comment #265)
> > Wat verbeteringen die ik zometeen wil toepassen. Het zijn heel kleine dingen
> > qua gebruik van de infinitief.
> 
> Ik zet eigenlijk alleen wat vraagtekens bij de labelwijzigingen in
> msgFolderPickerOverlay.dtd. Meen me te herinneren dat i.i.g. de kleine letters
> belangrijk waren, en zo even snel wat strings bekijkend geloof ik dat de oude
> werkwoordsvormen ook wat beter stonden dan infinitieven. Kan je/iemand hier nog
> even naar kijken?
Ik merk nu idd dat de oude vormen overeenkwamen met de engelse versie. Het
blijft echter zo dat het inconsisent is met het woordgebruik in de functies
kopiëren/verplaatsen in het contextmenu. 

Ik vind het goed om vormen van 'hier klikken' terug te veranderen, maar ik heb
het idee dat 'Deze map kiezen' e.d. wel goed zijn.

    
    

    
  
(In reply to comment #266)
> Ik merk nu idd dat de oude vormen overeenkwamen met de engelse versie. Het
> blijft echter zo dat het inconsisent is met het woordgebruik in de functies
> kopiëren/verplaatsen in het contextmenu. 
> 
> Ik vind het goed om vormen van 'hier klikken' terug te veranderen, maar ik heb
> het idee dat 'Deze map kiezen' e.d. wel goed zijn.

Mee eens.

Let ook op +<!ENTITY renamefolderchoosethis.label "Deze map map">..

    
    

    
  

      
      
      
      

        Attached patch
          
          
        2 access keys in cookiegedeelte (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  

      
      
      
      

        Attached patch
          
          
        enkele kleine verbeteringen (obsolete)
        — 
          — Splinter Review
      

    


  
het stukje `overeenkomen met... ' slaat op de daaropvolgende filters, meervoud
dus, vandaar ‘de’

    
    

    
  
(In reply to comment #269)
> Created an attachment (id=200264) [edit]
> enkele kleine verbeteringen
> 
> het stukje `overeenkomen met... ' slaat op de daaropvolgende filters, meervoud
> dus, vandaar ‘de’

Protest. Dit is een tijdje geleden al gewijzigd (dec. 2004) en als het goed is
in orde. Het slaat dan wel op de filterregels (uiteraard), maar meer op de
zichtbare inhoud ervan. Anders gezegd, 'de' is m.i. pas op zijn plaats als er
ook nog ergens 'regels' volgt of hieraan vooraf zou gaan.

Index: browser/os2/README.txt
===================================================================
-- Deze uitgave vereist geüpdate C runtime-DLL’s (libc-0.5.1) van
+- Deze uitgave vereist geüpdate C-runtime-DLL’s (libc-0.5.1) van

De discussie over updaten als werkwoord vs. bijwerken is eerder gevoerd en we
zouden toch bijwerken gebruiken, of is de mening daarover inmiddels veranderd?
Ik haal het net weg in prefs.xhtml.. Als er nu geen bezwaar meer is (ik vind het
wel OK), dan bovendien 'geüpdatet(e)'.

   op uw bootschijf, maar u kan ze in dezelfde map als het 

..u kunt.. ?

-     de C library-DLL’s naar de installatiemap zijn gekopieerd of 
+     de C-bibliotheek-DLL’s naar de installatiemap zijn gekopieerd of 

Zouden we niet gewoon library gebruiken? Zag deze wijziging ook in een andere
patch..

Index: mail/chrome/messenger/am-server-top.dtd
===================================================================
-<!ENTITY abbreviateOff.label "Afgekorte namen (bijvoorbeeld
‘n.p.m.mail-nieuws’)">
+<!ENTITY abbreviateOff.label "Afgekorte namen (bijvoorbeeld
‘n.p.m.mail-news’)">

Mee eens.

Index: mail/chrome/messenger/importDialog.dtd
===================================================================
-<!ENTITY importDesc.label "Importeren e-mail, adresboek en instellingen van
andere programma’s">
+<!ENTITY importDesc.label "E-mail, adresboek en instellingen van andere
programma’s importeren">

Mee eens.
 
Index: mail/chrome/messenger/searchTermOverlay.dtd
===================================================================
-<!ENTITY matchAll.label "Overeenkomen met al het volgende">
+<!ENTITY matchAll.label "Overeenkomen met al de volgende">
 <!ENTITY matchAll.accesskey "a">
-<!ENTITY matchAny.label "Overeenkomen met één van het volgende">
+<!ENTITY matchAny.label "Overeenkomen met één van de volgende">

Zie boven.

    
    

    
  
(In reply to comment #270)
> (In reply to comment #269)
> > Created an attachment (id=200264) [edit] [edit]
> > enkele kleine verbeteringen
> > 
> > het stukje `overeenkomen met... ' slaat op de daaropvolgende filters, meervoud
> > dus, vandaar ‘de’
> 
> Protest. Dit is een tijdje geleden al gewijzigd (dec. 2004) en als het goed is
> in orde. 

Ik vrees dat ik toen nog niet van de partij was...

> Het slaat dan wel op de filterregels (uiteraard), maar meer op de
> zichtbare inhoud ervan. Anders gezegd, 'de' is m.i. pas op zijn plaats als er
> ook nog ergens 'regels' volgt of hieraan vooraf zou gaan.

Ik denk dat ik snap wat je bedoelt, maar ik vind het een beetje vreemd om te
lezen wat er nu staat.  Ik lees het steeds als een elliptische zin, waar dus idd
 ‘regels’ is weggelaten: ‘Overeenkomen met {één van|al} de volgende (regels):’.
Wat is de redenering om ‘het’ te schrijven?  Het is toch ook _de_ inhoud.

> Index: browser/os2/README.txt
> ===================================================================
> -- Deze uitgave vereist geüpdate C runtime-DLL’s (libc-0.5.1) van
> +- Deze uitgave vereist geüpdate C-runtime-DLL’s (libc-0.5.1) van
> 
> De discussie over updaten als werkwoord vs. bijwerken is eerder gevoerd en we
> zouden toch bijwerken gebruiken, of is de mening daarover inmiddels veranderd?
> Ik haal het net weg in prefs.xhtml.. Als er nu geen bezwaar meer is (ik vind het
> wel OK), dan bovendien 'geüpdatet(e)'.

Ja, hum.  Ok, ik heb er de archieven op nagelezen, deze discussie schijnt
precies dan gevoerd geweest te zijn op het moment dat ik ben beginnen meedoen,
ik herinner me er nog flarden van.  Bijwerken dus.

>    op uw bootschijf, maar u kan ze in dezelfde map als het 
> 
> ..u kunt.. ?

Oeps.  Aangepast.
 
> -     de C library-DLL’s naar de installatiemap zijn gekopieerd of 
> +     de C-bibliotheek-DLL’s naar de installatiemap zijn gekopieerd of 
> 
> Zouden we niet gewoon library gebruiken? Zag deze wijziging ook in een andere
> patch..

Sorry, het is een beetje onduidelijk wat al wel of niet toegepast is. 
C-library-DLL’s dan?

Nog hierop antwoord, dan komt nieuwe patch.

    
    

    
  
(In reply to comment #270)
> -- Deze uitgave vereist geüpdate C runtime-DLL’s (libc-0.5.1) van
> +- Deze uitgave vereist geüpdate C-runtime-DLL’s (libc-0.5.1) van
> 
> De discussie over updaten als werkwoord vs. bijwerken is eerder gevoerd en we
> zouden toch bijwerken gebruiken, of is de mening daarover inmiddels veranderd?

Bijwerken. Ik heb dit zojuist aan het vertaalwoordenboek toegevoegd:

Update = update
Updaten = bijwerken

Al moet ik wel zeggen dat ik het jammer vind dat we zo vaak update zeggen en
niet "nieuwe versie", of "bijgewerkte versie":

"Automatisch controleren op nieuwe versies voor:"
"Wanneer er nieuwe versies van Firefox zijn gevonden:"
"Automatisch de nieuwe versie downloaden en installeren:"

Maar goed, het is ook wel goed zoals het nu is, en in ieder geval een stuk
eenvoudiger.

Ik heb ook twee items over "upgrade" toegevoegd, maar dat is eigenlijk vrij loos
aangezien dat woord nauwelijks wordt gebruikt in Firefox (en er zo goed als geen
onderscheid wordt gemaakt).


> -     de C library-DLL’s naar de installatiemap zijn gekopieerd of 
> +     de C-bibliotheek-DLL’s naar de installatiemap zijn gekopieerd of 
> 
> Zouden we niet gewoon library gebruiken? Zag deze wijziging ook in een andere
> patch..

Aangezien we ook gewoon runtime zeggen...

Daarentegen wordt bibliotheek op zich ook wel gebruikt, dus wat dat betreft is
er ook niet in het bijzonder iets op tegen.


~Grauw

    
    

    
  
(In reply to comment #270)
> (In reply to comment #269)
> > Created an attachment (id=200264) [edit] [edit]
> > enkele kleine verbeteringen
> > 
> > het stukje `overeenkomen met... ' slaat op de daaropvolgende filters, meervoud
> > dus, vandaar ‘de’
> 
> Protest. Dit is een tijdje geleden al gewijzigd (dec. 2004) en als het goed is
> in orde. Het slaat dan wel op de filterregels (uiteraard), maar meer op de
> zichtbare inhoud ervan. Anders gezegd, 'de' is m.i. pas op zijn plaats als er
> ook nog ergens 'regels' volgt of hieraan vooraf zou gaan.

Ik heb gekeken in Thunderbird, en daar lees ik in de betreffende regel geen
impliciet "regels". Er staat "Overeenkomen met al het volgende", en dan een
lijst van stellingen, bijv. "Onderwerp bevat Mozilla". En daarom is het zoals
het nu is correct.

Vergelijk:

Berichten zoeken in Postvak IN, overeenkomende met al het volgende:
- "Onderwerp" bevat "Mozilla"
- "Van" bevat geen "Laurens Holst"

Met:

Berichten zoeken in Postvak IN, overeenkomende met al de volgende:
- "Onderwerp" bevat "Mozilla"
- "Van" bevat geen "Laurens Holst"

En hopelijk snap je wat ik (en Ton) bedoel.


~Grauw

    
    

    
  
We zouden wel beter "overeenkomende met" of "die overeen komen met" kunnen
schrijven, denk ik.

~Grauw

    
    

    
  
Comment on attachment 200246 [details] [diff] [review]
2 access keys in cookiegedeelte

Toegepast op branch en trunk

        Attachment #200246 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #267)
> (In reply to comment #266)
> > Ik merk nu idd dat de oude vormen overeenkwamen met de engelse versie. Het
> > blijft echter zo dat het inconsisent is met het woordgebruik in de functies
> > kopiëren/verplaatsen in het contextmenu. 
> > 
> > Ik vind het goed om vormen van 'hier klikken' terug te veranderen, maar ik heb
> > het idee dat 'Deze map kiezen' e.d. wel goed zijn.
> 
> Mee eens.
> 
> Let ook op +<!ENTITY renamefolderchoosethis.label "Deze map map">..
Dit is nu terugveranderd. Zie bonsai voor de preciese regels die veranderd zijn.

Is Ton het nu trouwens wel eens met de koppelstreepjes in de homepage patch van
Laurens. Wat mij betreft kan deze toegepast worden.

Verder ook graag een gewijzigde patch met de laatste wijzigingen van Hendrik,
voordat deze toegepast kan worden.

    
    

    
  
(In reply to comment #276)
> 
> Is Ton het nu trouwens wel eens met de koppelstreepjes in de homepage patch van
> Laurens. Wat mij betreft kan deze toegepast worden.

We kunnen het probleem omzeilen door er in de bewuste gevallen net zoals nu
dacht ik in FF 'de homepage van xx' van te maken (misschien zelfs mooier?), maar
voer hem wat mij betreft maar door, al is het alleen al vanwege de voortgang. :)
Het andere kan evt. later nog.

Maar bedenk dan dat ook nog andere strings moeten worden gewijzigd, zoals
Firefox startpagina/productpagina etc. in de bladwijzers. Hmm.. het voelt al
meteen raar, zie de klemtoon daarvan ook verlegd worden. Zal door de lijst met
verschillende Firefox-koppelingen komen.

Heb nog gezocht naar verklaring 'ter verdediging' maar met de taalregels kom ik
er niet, althans niet als ik blijf zoeken in de samenstellingen vs. woordgroepen
of spatiegebruik en andere concrete voorbeelden dan bv. 'Mozbrowser forum' en de
hamsterweken kan ik even niet verzinnen, maar het idee is denk ik duidelijk.

Begrijp me niet verkeerd, ik begin te geloven dat ik er echt naast zit met mijn
theorie en ergens hoop ik het zelfs, in de hoop dat daarmee (de verwarring en)
het onterecht spatiegebruik afneemt doordat er a.h.w. maar 1 mogelijkheid is.
Gek genoeg heb ik de theorie van het geoorloofde gebruik altijd voor waar
aangenomen en ik vind het ook logischer lezen, zoals ik al zei dankzij de
klemtoon. Daarom vind ik onterecht spatiegebruik zo irritant, omdat het meteen
de klemtoon verlegt en dus zo'n 'subgevoel' geeft. Of het iets met het Engels te
maken heeft, het lijkt me onmogelijk (hoe bepaal je daar de klemtoon?) maar ik
kan het mis hebben.


    
    

    
  

      
      
      
      

        Attached patch
          
          
        3 kleinigheidjes (obsolete)
        — 
          — Splinter Review
      

    


  
N.a.v. sinds kort bestaand domein, niet handig.

    
    

    
  
(In reply to comment #277)
> (In reply to comment #276)
> We kunnen het probleem omzeilen door er in de bewuste gevallen net zoals nu
> dacht ik in FF 'de homepage van xx' van te maken (misschien zelfs mooier?),
> maar voer hem wat mij betreft maar door, al is het alleen al vanwege de
> voortgang. :) Het andere kan evt. later nog.

Idd.


> Maar bedenk dan dat ook nog andere strings moeten worden gewijzigd, zoals
> Firefox startpagina/productpagina etc. in de bladwijzers. Hmm.. het voelt al
> meteen raar, zie de klemtoon daarvan ook verlegd worden. Zal door de lijst met
> verschillende Firefox-koppelingen komen.

Dat hangt er vanaf, als startpagina hier naar start.mozilla.org/firefox wijst
dan is het wel goed.


> Heb nog gezocht naar verklaring 'ter verdediging' maar met de taalregels kom
> ik er niet, althans niet als ik blijf zoeken in de samenstellingen vs.
> woordgroepen of spatiegebruik en andere concrete voorbeelden dan bv.
> 'Mozbrowser forum' en de hamsterweken kan ik even niet verzinnen, maar het
> idee is denk ik duidelijk.

Ja, dat probeerde ik dus ook en ik kon geen goede regels vinden die het
bevestigden noch ontkrachtten (tenminste niet bij mijn zoektocht naar
woordgroepen, samenstellingen en liggende streepjes, maar misschien heet het wel
heel anders). Nuja, Riagg-centrum, maar daarbij was het omdat Riagg een
afkorting was. Raar dat dat zo moeilijk is, het is toch vrij fundamenteel zou je
zeggen.


~Grauw

    
    

    
  
Als ik op uitgaveopmerkingen klik in Thunderbird, gaat hij naar:

http://www.mozilla-nl.org/releases/

En krijg ik een 404 not found.


~Grauw

    
    

    
  
Comment on attachment 200394 [details] [diff] [review]
3 kleinigheidjes

Toegepast op branch en trunk

We moeten imo nog wel kijken naar .net.nz, het heeft namelijk niet zoveel met
Nederland te maken. Andere vertalingen hebben nz hier gewoon vertaald, maar
omdat .net.nl niet bestaat (en .net.nz wel) heb ik de patch gewoon toegepast.
Misschien moet er een algemene dicussie over gevoerd worden.

        Attachment #200394 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 200064 [details] [diff] [review]
Startpagina -> homepage, waar van toepassing (nieuw)

Toegepast op branch en trunk

Ik heb hier wel ipv 'Bezoek homepage' 'Homepage bezoeken' toegepast (in
extensions/about.dtd). Dit om het hetzelfde te noemen als in het contextmenu.

        Attachment #200064 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #280)
> Als ik op uitgaveopmerkingen klik in Thunderbird, gaat hij naar:
> 
> http://www.mozilla-nl.org/releases/
> 
> En krijg ik een 404 not found.
Bij mij gaat hij naar
http://www.mozilla.org/products/thunderbird/releases/1.5.html. Die bestaat nog
niet. Gebruik je de laatste Thunderbird nightly en bezoek je de
uitgaveopmerkingen via Help > ..?

Misschien dat we de URL moeten veranderen naar
mozilla-nl.org/projecten/thunderbird/releases? Daar zijn wel vertaalde
releasenotes te lezen.

Ik heb trouwens zonet ook 2 verbredingen voor 2 optievenster toegepast. In
Ubuntu waren deze iets te smal. Op Mac OS X heb ik over soort gelijke problemen
gehoord.

    
    

    
  
(In reply to comment #281)
> (From update of attachment 200394 [details] [diff] [review] [edit])
> Toegepast op branch en trunk
> 
> We moeten imo nog wel kijken naar .net.nz, het heeft namelijk niet zoveel met
> Nederland te maken. Andere vertalingen hebben nz hier gewoon vertaald, maar
> omdat .net.nl niet bestaat (en .net.nz wel) heb ik de patch gewoon toegepast.
> Misschien moet er een algemene dicussie over gevoerd worden.

Juiste beslissing. Ik weet niet precies wat er algemeen over valt te
discussieren. Het komt in Nederland niet voor, dus het voorbeeldje valt niet
specifiek naar het Nederlands te ‘vertalen’, maar het is nog steeds van
toepassing als je uitzonderingen wilt maken voor adressen zoals yahoo.co.uk.


~Grauw

    
    

    
  
(In reply to comment #283)
> Bij mij gaat hij naar
> http://www.mozilla.org/products/thunderbird/releases/1.5.html. Die bestaat nog
> niet. Gebruik je de laatste Thunderbird nightly en bezoek je de
> uitgaveopmerkingen via Help > ..?

Hm. Ik gebruik zie ik nu de nl nightly van 20050822, dus dat is wel even
geleden. Maar eens nieuwe versie downloaden weer.


> Misschien dat we de URL moeten veranderen naar
> mozilla-nl.org/projecten/thunderbird/releases? Daar zijn wel vertaalde
> releasenotes te lezen.

Weet ik niet. Het is meer low-maintenance als we het gewoon naar de Mozilla.org
release notes laten wijzen, dus persoonlijk heeft dat mijn voorkeur, maar als
mozilla-nl.org echt goed bijgehouden wordt (ook met point releases), dan vind ik
dat ook best.


> Ik heb trouwens zonet ook 2 verbredingen voor 2 optievenster toegepast. In
> Ubuntu waren deze iets te smal. Op Mac OS X heb ik over soort gelijke problemen
> gehoord.

Sure.


~Grauw

    
    

    
  
(In reply to comment #277)
> We kunnen het probleem omzeilen door er in de bewuste gevallen net zoals nu
> dacht ik in FF 'de homepage van xx' van te maken (misschien zelfs mooier?), 

Ben ik ook voor.

[Betreft spatiegebruik]  Laat je eventueel ook inspireren door de leuke site SOS
-- Signalering Onjuist Spatiegebruik: http://www.spatiegebruik.nl/

(In reply to comment #278)
> N.a.v. sinds kort bestaand domein, niet handig.

Waarom moet dit? (niet dat ik er iets op tegen heb)
Wat maakt het uit of .net.nl bestaat of niet?  De regel is geldig, al zal hij
geen effect hebben...  Overigens kan er toch even goed .net.nz staan, mensen
bezoeken toch websites over heel de wereld en niet alleen in het Nederlands (ga
ik maar even van uit :-/)






    
    

    
  

      
      
      
      

        Attached patch
          
          
        commentaar verwerkt (obsolete)
        — 
          — Splinter Review
      

    


  
Commentaar verwerkt, verder nog meer wijzigingen w.b. u kunt en bijwerken vs.
updaten.

        Attachment #200264 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        nog maar eens toolkit (obsolete)
        — 
          — Splinter Review
      

    


  
Gezien de laatste wijzigingen zou dit problemen opleveren, maar ik zou het leuk
vinden als hier eindelijk eens werk van wordt gemaakt (is het bv. juist dat ik
nl-NL door nl vervangen heb enz.?).

        Attachment #199672 -
        Attachment is obsolete: true

    
    

    
  


  
Enkele zinnen van volgorde veranderd om het beter te laten bekken.

Overigens zit in de vorige ook de omzetting van prompt -> vraag, vergeten
melden

    
  
Depends on: 313482

    
    

    
  
(In reply to comment #274)
> 
> We zouden wel beter "overeenkomende met" of "die overeen komen met" kunnen
> schrijven, denk ik.

In het eerste geval zonder 'die' erboven neem ik aan? Tja.. zou kunnen maar is het echt zo veel mooier? Het wordt alleen wat formeler IMO. 'Overeen komen' los schrijven is denk ik niet raadzaam; als ik me niet vergis wordt dat meestal aan elkaar geschreven, of is het zelfs de regel.

(In reply to comment #279)
> 
> > Maar bedenk dan dat ook nog andere strings moeten worden gewijzigd, zoals
> > Firefox startpagina/productpagina etc. in de bladwijzers. Hmm.. het voelt al
> > meteen raar, zie de klemtoon daarvan ook verlegd worden. Zal door de lijst met
> > verschillende Firefox-koppelingen komen.
> 
> Dat hangt er vanaf, als startpagina hier naar start.mozilla.org/firefox wijst
> dan is het wel goed.

Ik bedoelde hiermee de koppelstreepjes, niet de kwestie home/start. Die moeten hier dan toch ook komen? Misschien is dit deel van de bladwijzers ook wel een goed voorbeeld van wat ik bedoelde, althans zoals ik het dus lees (klemtoonaspect en sub/onderverdeling). Ook dacht ik nog aan voorbeelden als 'TU Délft', Hogeschool Rotterdám' en 'Mozbrowser fórum', op de Mózbrowser-site zelf.

Vergelijk het huidige

Firefox stártpagina
Firefox Céntral (weliswaar Engels, maar toch)
Firefox prodúctpagina
De Mozilla wébsite
(Mozilla Néderland)

etc. met het evt. nieuwe

Fírefox-startpagina
Firefox Céntral (blijft Engels, en dus ook deze klemtoon)
Fírefox-productpagina
De Mozílla-website
Mozilla Néderland (blijft zo, en tja.. zegt misschien ook wat?)

> Ja, dat probeerde ik dus ook en ik kon geen goede regels vinden die het
> bevestigden noch ontkrachtten (tenminste niet bij mijn zoektocht naar
> woordgroepen, samenstellingen en liggende streepjes, maar misschien heet het wel
> heel anders). Nuja, Riagg-centrum, maar daarbij was het omdat Riagg een
> afkorting was. Raar dat dat zo moeilijk is, het is toch vrij fundamenteel zou je
> zeggen.

Precies.. Ik kan me ook niet voorstellen dat het compleet uit het niets komt, of Hendrik moet zoiets bedoelen met de invloed uit het Engels? Ik bedoel, dat het eigenlijk een soort denkbeeldig/verzonnen voordeel is? :-/

Ik zou het overigens wel een aardige regel vinden i.i.g., al betwijfel ik of het veel nut heeft gezien de problemen met het huidige spatiegebruik. Of misschien daarom juist weer wel..

    
    

    
  
(In reply to comment #290)
> (In reply to comment #274)
> > We zouden wel beter "overeenkomende met" of "die overeen komen met" kunnen
> > schrijven, denk ik.
> 
> In het eerste geval zonder 'die' erboven neem ik aan? Tja.. zou kunnen maar is
> het echt zo veel mooier? Het wordt alleen wat formeler IMO. 'Overeen komen'
> los schrijven is denk ik niet raadzaam; als ik me niet vergis wordt dat meestal
> aan elkaar geschreven, of is het zelfs de regel.

Los of vast gaat het mij niet om, maar ik zou zeggen: of ‘die’ ervoor, of ‘overeenkomende’ gebruiken, lijkt me. Er staat nu iig geen die, en zo is het volgens mij niet correct.


~Grauw

    
    

    
  
(In reply to comment #291)
> (In reply to comment #290)
> > (In reply to comment #274)
> > > We zouden wel beter "overeenkomende met" of "die overeen komen met" kunnen
> > > schrijven, denk ik.
> > 
> > In het eerste geval zonder 'die' erboven neem ik aan? Tja.. zou kunnen maar is
> > het echt zo veel mooier? Het wordt alleen wat formeler IMO. 'Overeen komen'
> > los schrijven is denk ik niet raadzaam; als ik me niet vergis wordt dat meestal
> > aan elkaar geschreven, of is het zelfs de regel.
> 
> Los of vast gaat het mij niet om, maar ik zou zeggen: of ‘die’ ervoor, of
> ‘overeenkomende’ gebruiken, lijkt me. Er staat nu iig geen die, en zo is het
> volgens mij niet correct.

Vandaar.. het 'die' staat er namelijk boven. :) Hendrik heeft ze overigens in attachment 200474 [details] [diff] [review] vervangen door '(die) Voldoen aan ..'  van gemaakt, wat me wel OK lijkt.

Zit overigens vanavond even op irc.


    
    

    
  
(In reply to comment #287)
> Created an attachment (id=200474) [edit]

Ok.

(In reply to comment #288)
> Created an attachment (id=200475) [edit]
> nog maar eens toolkit
> 
> Gezien de laatste wijzigingen zou dit problemen opleveren, maar ik zou het leuk
> vinden als hier eindelijk eens werk van wordt gemaakt (is het bv. juist dat ik
> nl-NL door nl vervangen heb enz.?).

Ik denk het wel maar weet het niet zeker.

Verder wat opmerkingen:

printPageSetup.dtd
'Linkse tekst' etc. zie ik ook niet zo zitten, doet me denken aan politieke kleur. Linker en rechter los lijkt me echt juist, maar als anderen er ook iets tegen hebben dan moet het maar aan elkaar met als argument dat het zeer ingeburgerde termen zijn (liever niet). Zie ook http://www.onzetaal.nl/advies/linker.html.

printjoboptions.dtd
+<!ENTITY edgeMarginInput.label "Ruimte tussen rand en marge">

Geen 'papierrand'?

xpinstall.properties
Je hebt blijkbaar iets tegen 'Bezig ..'. Persoonlijk vind ik dit hier niet misstaan, alhoewel 'Bezig met' <infintief> van <ding>' mooier is. Het geeft een goed idee van huidige installatiestatus. Maar alla, het is wel vaker infinitief. Hebben we het hier niet al eens over gehad?

extensions.properties
vanwege->wegens

Wat is toch het preciese bezwaar tegen 'vanwege', voor reden/oorzaak kan dit toch allebei?

update.dtd
installing.intro.label          "Nu downloaden en installeren van nieuwe versies...">

Kun je deze string ook nog wijzigen, 'updates' is hier beter op zijn plaats. Beter misschien nog: 'Updates (nu) aan het downloaden en installeren...' (of 'Bezig met..') Liever ook hier geen infinitief vanwege verloren statusinformatie. Die is er nu ook niet, maar correct is de zin i.i.g. niet.

- wanneer compatibele versies beschikbaar komen.">
+ wanneer compatibele versies beschikbaar worden.">
(3x)

Er is v.z.i.w. geen bezwaar tegen 'beschikbaar komen'. 'Worden' is denk ik wat letterlijk vertaald en klinkt nogal vreemd, tenzij in 'beschikbaar worden gesteld' (waar ik overigens niet voor pleit, maar wat ook nog kan).

update.properties
door -> wegens
Hmm.. zou hier zelf ook 'vanwege' van maken, maar vraag niet waarom.

pulgins.dtd
-<!ENTITY pluginWizard.title "Plugin-zoekservice">
+<!ENTITY pluginWizard.title "Pluginzoekservice">

Met koppelteken niet beter leesbaar? (Klemtoon meer op 'zoek' bij koppelteken)

plugins.properties
-pluginInstallation.download.start=%S aan het downloaden...
+pluginInstallation.download.start=%S downloaden...

Net als 'bezig..' Ik zou het zo laten, maar ja.. Misschien zijn dergelijke 'voortgangskwesties' iets voor het vertaalwoordenboek?

fontscaling.dtd
-<!ENTITY  units.inches                            "inches">
+<!ENTITY  units.inches                            "duim">

Is dit handig? In tekst elders en dagelijks gebruik toch ook inches?

removemp.dtd
-<!ENTITY removeWarning2.label              "Als u uw hoofdwachtwoord verwijdert .. uw computer wordt overgedragen.">
+<!ENTITY removeWarning2.label              "Als u uw hoofdwachtwoord verwijdert .. uw computer wordt bedreigd">

'Compromised' is elders vertaald als 'overgenomen', dus hier misschien ook beter? Compromitteren is volgens Van Dale 'verdacht maken', maar ik heb het altijd gelezen als 'gekaapt', dus overgenomen.. Misschien ook een komma achter 'verwijdert'?

createprofilewizard.dtd
-<!ENTITY profileCreationExplanation_3.text "... Bijvoorbeeld, u wilt misschien aparte profielen hebben voor zakelijk en persoonlijk gebruik.">
+<!ENTITY profileCreationExplanation_3.text "... Bijvoorbeeld wilt u misschien aparte profielen hebben voor zakelijk en persoonlijk gebruik.">

Het oude leest misschien raar vanwege (.?.) de twee bepalingen 'misschien' en 'bijvoorbeeld', maar het nieuwe vind ik niet echt beter. Je zou haast zeggen dat een van de twee bepalingen best weg kan en het in te korten is tot 'U wilt bijvoorbeeld', 'Zo wilt u bijvoorbeeld' of 'Zo wilt u misschien', maar de betekenis verandert dan dus dat is eigenlijk geen optie, hoewel 'Zo wilt u misschien' wel lekker bekt en overkoepelend genoeg werkt. Anders komt ik steeds bij de huidige vorm terecht. 'Bijvoorbeeld' aan het begin van een zin zonder komma zie ik niet vaak, tenzij het onderdeel is van een onderwerp.

(In reply to comment #289)
> Created an attachment (id=200476) [edit]
> betere formulering i.v.m. infinitieven
> 
> Enkele zinnen van volgorde veranderd om het beter te laten bekken.

Ok.



    
    

    
  
(In reply to comment #292)
> 
> Vandaar.. het 'die' staat er namelijk boven. :) Hendrik heeft ze overigens in
> attachment 200474 [details] [diff] [review] [edit] vervangen door '(die) Voldoen aan ..'  van gemaakt, wat me
> wel OK lijkt.

Correctie, we keken denk ik naar verschillende menuonderdelen. Alleen in de berichtenfilters staat de string 'Voor inkomende berichten die' erboven, bij zoeken naar berichten of in adresboek staat daar idd niets. Er moet dus iets passends komen wat in alle gevallen goed staat. Misschien meest voor de hand liggend om er dan idd 'Overeenkomend met' van te maken en 'die' weg te halen?

Ergens jammer, want voor de filterregels was 'voldoen aan' wel een goede oplossing (kan een bericht immers wel overeenkomen met een aantal criteria ervoor?). Maar of overal 'Voldoend aan' nou zo'n goed idee is..

Ik pleit voor aparte entities.


    
    

    
  
(In reply to comment #293)
> printPageSetup.dtd
> 'Linkse tekst' etc. zie ik ook niet zo zitten, doet me denken aan politieke
> kleur. Linker en rechter los lijkt me echt juist, maar als anderen er ook iets
> tegen hebben dan moet het maar aan elkaar met als argument dat het zeer
> ingeburgerde termen zijn (liever niet). Zie ook
> http://www.onzetaal.nl/advies/linker.html.

Zie het als een voorstel mijnentwege, ik kan er ook mee leven als het blijft zoals het is, maar vind dit beter.
 
> xpinstall.properties
> Je hebt blijkbaar iets tegen 'Bezig ..'. 

Inderdaad.  Ik vind het nogal spreektalig en een te letterlijke vertaling van de hoe-heet-ie-ook-weer tijd in het Engels.  Het is typisch dat bij een eerste vertaling zulke dingen optreden, maar bij een tweede revisie bekijk ik het zonder rekening te houden met het origineel.  Ik zou bv. nooit in een eigen tekst `bezig met <inf>' of `bezig te <inf>' schrijven.

> Hebben we het hier niet al eens over gehad?

Kan wel, ik moet misschien eens een lijstje bijhouden, of zulke dingen zouden op de vertaalpagina mogen.
 
> extensions.properties
> vanwege->wegens
> 
> Wat is toch het preciese bezwaar tegen 'vanwege', voor reden/oorzaak kan dit
> toch allebei?

Vanwege lees ik alsof iets ergens vandaan komt.  Zie http://www.onzetaal.nl/advies/wegens.html, de derde betekenis.  Zal wel weer een nl <> be ding zijn, want als ik even snel vanwege google, dan kom ik op de eerste pagina's alleen .nl-sites tegen.

> - wanneer compatibele versies beschikbaar komen.">
> + wanneer compatibele versies beschikbaar worden.">
> (3x)
> 
> Er is v.z.i.w. geen bezwaar tegen 'beschikbaar komen'. 'Worden' is denk ik wat
> letterlijk vertaald en klinkt nogal vreemd, tenzij in 'beschikbaar worden
> gesteld' (waar ik overigens niet voor pleit, maar wat ook nog kan).

Je schijnt gelijk te hebben, al vind ik het raar klinken.

> update.properties
> door -> wegens
> Hmm.. zou hier zelf ook 'vanwege' van maken, maar vraag niet waarom.

Tsja, zie boven.
 
> pulgins.dtd
> -<!ENTITY pluginWizard.title "Plugin-zoekservice">
> +<!ENTITY pluginWizard.title "Pluginzoekservice">
> 
> Met koppelteken niet beter leesbaar? (Klemtoon meer op 'zoek' bij koppelteken)

Ik heb het in ieder geval niet nodig om eenduidig de betekenis vast te stellen (niet zoals val-kuil vs. valk-uil; zulke woorden waren de reden voor die leesbaarheidsuitzondering, niet iets zoals dit (tenminste, dat is mijn interpretatie))
 
> plugins.properties
> -pluginInstallation.download.start=%S aan het downloaden...
> +pluginInstallation.download.start=%S downloaden...
> 
> Net als 'bezig..' Ik zou het zo laten, maar ja.. Misschien zijn dergelijke
> 'voortgangskwesties' iets voor het vertaalwoordenboek?

Mee eens.  Ik vind `aan het' gewoon overbodig, maar kan er wel mee leven.  Afstemmen, dan in woordenboek en consequent aanhouden.

> fontscaling.dtd
> -<!ENTITY  units.inches                            "inches">
> +<!ENTITY  units.inches                            "duim">
> 
> Is dit handig? In tekst elders en dagelijks gebruik toch ook inches?

Nee.  In de computerwereld misschien, maar als je een timmerman vraagt, zal hij zeker van duim spreken.  Overigens toch van ondergeschikt belang, daar deze string in de nl versie wsch niet gebruikt wordt?  (Of misschien in een keuzemenuutje)
 
> removemp.dtd
> -<!ENTITY removeWarning2.label              "Als u uw hoofdwachtwoord
> verwijdert .. uw computer wordt overgedragen.">
> +<!ENTITY removeWarning2.label              "Als u uw hoofdwachtwoord
> verwijdert .. uw computer wordt bedreigd">
> 
> 'Compromised' is elders vertaald als 'overgenomen', dus hier misschien ook
> beter? Compromitteren is volgens Van Dale 'verdacht maken', maar ik heb het
> altijd gelezen als 'gekaapt', dus overgenomen.. Misschien ook een komma achter
> 'verwijdert'?

`To expose or make liable to danger, suspicion, or disrepute: an embassy that was compromised by hidden listening devices.'  Juister zou dus zijn `indien uw computer aan gevaar wordt blootgesteld', maar dat past niet echt in de zin.  Misschien overgenomen? Overgedragen komt op mij actief over, wat het in dit geval zeker niet is.  (Vandaar mijn verandering)

> createprofilewizard.dtd
> -<!ENTITY profileCreationExplanation_3.text "... Bijvoorbeeld, u wilt misschien
> aparte profielen hebben voor zakelijk en persoonlijk gebruik.">
> +<!ENTITY profileCreationExplanation_3.text "... Bijvoorbeeld wilt u misschien
> aparte profielen hebben voor zakelijk en persoonlijk gebruik.">
> 
> Het oude leest misschien raar vanwege (.?.) de twee bepalingen 'misschien' en
> 'bijvoorbeeld', maar het nieuwe vind ik niet echt beter. Je zou haast zeggen
> dat een van de twee bepalingen best weg kan en het in te korten is tot 'U wilt
> bijvoorbeeld', 'Zo wilt u bijvoorbeeld' of 'Zo wilt u misschien', maar de
> betekenis verandert dan dus dat is eigenlijk geen optie, hoewel 'Zo wilt u
> misschien' wel lekker bekt en overkoepelend genoeg werkt. Anders komt ik steeds
> bij de huidige vorm terecht. 'Bijvoorbeeld' aan het begin van een zin zonder
> komma zie ik niet vaak, tenzij het onderdeel is van een onderwerp.

`U zou bijvoorbeeld aparte profielen kunnen hebben voor zakelijk en persoonlijk gebruik'? 

(In reply to comment #294)
> > attachment 200474 [details] [diff] [review] [edit] [edit] vervangen door '(die) Voldoen aan ..'  van gemaakt, wat me
> > wel OK lijkt.
> 
> Correctie, we keken denk ik naar verschillende menuonderdelen. Alleen in de
> berichtenfilters staat de string 'Voor inkomende berichten die' erboven, bij
> zoeken naar berichten of in adresboek staat daar idd niets. Er moet dus iets
> passends komen wat in alle gevallen goed staat. Misschien meest voor de hand
> liggend om er dan idd 'Overeenkomend met' van te maken en 'die' weg te halen?

Ah, dat had ik ook niet door, ik heb alleen naar de filterregels gekeken.
 
> Ergens jammer, want voor de filterregels was 'voldoen aan' wel een goede
> oplossing (kan een bericht immers wel overeenkomen met een aantal criteria
> ervoor?). Maar of overal 'Voldoend aan' nou zo'n goed idee is..
> 
> Ik pleit voor aparte entities.

Ik ook.


    
    

    
  
Enkele interessante artikeltjes over de wijzigingen in de spelling, die toch gedeeltelijk betrekking hebben op zaken die we hier al bediscussieerd hebben, vooral dan rond streepjesgebruik: http://www.onzetaal.nl/advies/spellingconcreet.html.  

    
    

    
  
Comment on attachment 200474 [details] [diff] [review]
commentaar verwerkt

toegepast op branch en trunk

        Attachment #200474 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 200476 [details] [diff] [review]
betere formulering i.v.m. infinitieven

Toegepast op branch en trunk

Wel 1 vraag over deze patch: Wijzigingen zijn goed, maar ik verwacht dat we nu ook Help > Controleren op updates... willen aanpassen in zowel FF als TB? Moet ik dat wijzigen of neemt iemand dat mee in een volgende patch.

Ik heb trouwens vanmiddag ook nog een accesskey gefixed in het contextmenu van de extensiebeheerder. Dat was vergeten in de homepagepatch van Laurens.

        Attachment #200476 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        bookmarks.patch (obsolete)
        — 
          — Splinter Review
      

    


  
Deze patch heb ik vandaag toegepast om te voldoen aan de eisen van de QA:
"
Please adjust your locales to follow these two bugs, we're short on time now.

Some rules:

- searchengine plugins: Any two searchplugins in our repository with the same file name must be identical, up to the char. images are named like the search engine plugin. No non-shipped plugins in CVS, do use cvs remove. No dictionaries.com.

- bookmarks: get rid of extra links. I have said that before, I'll repeat, you want one page for your community, which is the localization of the mozillazine link (not necessarily a localization of the site). Multiple links are just confusing. One feed of use to general audience.

Please start working on this, we won't ship locales that don't pass trademarks review, and the longer you take for that, the harder it is going to get that review. "

    
    

    
  
(In reply to comment #298)
> (From update of attachment 200476 [details] [diff] [review] [edit])
> Toegepast op branch en trunk
> 
> Wel 1 vraag over deze patch: Wijzigingen zijn goed, maar ik verwacht dat we nu
> ook Help > Controleren op updates... willen aanpassen in zowel FF als TB? Moet
> ik dat wijzigen of neemt iemand dat mee in een volgende patch.

Misschien handig als Hendrik dat doet, die was er mee bezig?

Ik weet nu trouwens weer waarom de strings waren zoals ze waren: met opzet was het werkwoord achteraan geplaatst bij gebruikeracties, en vooraan bij statusinfo, ofwel een actie van FF/TB. Als we dan toch vaker infinitief gebruiken is dat wellicht handig om toch een verschil te behouden? Vergelijk bijvoorbeeld ook 'Gedeeld bestand installeren:' met 'Installeren gedeeld bestand:' (zoals in vorige patch). Allebei infinitief, maar toch een duidelijk verschil.

> Ik heb trouwens vanmiddag ook nog een accesskey gefixed in het contextmenu van
> de extensiebeheerder. Dat was vergeten in de homepagepatch van Laurens.

Ok, maar hij gaat wel botsen met de nog te wijzigen key (k->b) voor 'bovenkant' in attachment 200475 [details] [diff] [review]. Misschien van de laatste een v maken? 'Bovenkant' mag van mij overigens ook 'top' zijn, dan komt de v ook mooier uit.

    
    

    
  
(In reply to comment #295)
> Vanwege lees ik alsof iets ergens vandaan komt.  Zie
> http://www.onzetaal.nl/advies/wegens.html, de derde betekenis.  Zal wel weer
> een nl <> be ding zijn, want als ik even snel vanwege google, dan kom ik op de
> eerste pagina's alleen .nl-sites tegen.

Beiden zijn goed. Dus ik zou het zo laten. Vanwege betekent in Nederland hetzelfde als wegens. De betekenis van ergens vandaan komen lijkt me idd een Vlaams ding.


> > - wanneer compatibele versies beschikbaar komen.">
> > + wanneer compatibele versies beschikbaar worden.">
> 
> Je schijnt gelijk te hebben, al vind ik het raar klinken.

Beschikbaar worden vind ik inderdaad een beetje vreemd.


> > update.properties
> > door -> wegens
> > Hmm.. zou hier zelf ook 'vanwege' van maken, maar vraag niet waarom.
> 
> Tsja, zie boven.

Ik ben het in ieder geval eens met het vervangen van door. Of het nou vanwege of wegens wordt maakt mij niet uit.


> > pulgins.dtd
> > -<!ENTITY pluginWizard.title "Plugin-zoekservice">
> > +<!ENTITY pluginWizard.title "Pluginzoekservice">
> > 
> > Met koppelteken niet beter leesbaar? (Klemtoon meer op 'zoek' bij koppelteken)

Ik lees het zonder koppelteken als Pluginzoek-service. Weet niet of dat gewenst is.


> > fontscaling.dtd
> > -<!ENTITY  units.inches                            "inches">
> > +<!ENTITY  units.inches                            "duim">
> > 
> > Is dit handig? In tekst elders en dagelijks gebruik toch ook inches?
> 
> Nee. In de computerwereld misschien, maar als je een timmerman vraagt, zal hij
> zeker van duim spreken.  Overigens toch van ondergeschikt belang, daar deze
> string in de nl versie wsch niet gebruikt wordt?  (Of misschien in een
> keuzemenuutje)

Ik ben het absoluut niet eens met deze wijziging.

Juist omdat er in de computerwereld exclusief sprake is van inches (en we die maat in Nederland uberhaupt niet gebruiken) is het geen goed idee om ‘duim’ als term te hanteren, dat verwart alleen maar. Bovendien is zoals je op de onderstaande pagina ziet een Nederlandse duim ook helemaal niet dezelfde maat als het Engelse inch (net zoals bij pond/pound, ons/ounce en pint/pint en mijl/mile).

Wikipedia: http://nl.wikipedia.org/wiki/Duim

# een Engelse lengtemaat, in sommige beroepsgroepen ook duim genoemd; zie inch
# een oud-nederlandse lengtemaat; zie duim (lengtemaat)

En, op: http://nl.wikipedia.org/wiki/Inch

Het Nederlandse equivalent van een inch is een duim. Dit begrip leeft nog voort in o.a. het woord duimstok, maar de eenheid wordt in Nederland niet officieel meer gebruikt. In de industrie en de bouw wordt de duim nog wel gebruikt (bijv. een 3-duims pijp of een 1-duims dikke plaat hout). Andere zaken waarvan de maat nog vaak in inch aangeduid worden zijn (computer)beeldschermen, inbouwmaten van harde schijven en floppy-disks, de diameters van banden en velgen van auto's en (motor)fietsen.

Niet dat ik hiermee wil zeggen dat Wikipedia nou zo’n betrouwbare maatstaf is, maar wat daar staat klopt wel. Niet de computerwereld is de uitzondering dat die over inch spreekt, maar juist beroepgroepen als timmermannen zijn de uitzondering.


> > removemp.dtd
> > -<!ENTITY removeWarning2.label              "Als u uw hoofdwachtwoord
> > verwijdert .. uw computer wordt overgedragen.">
> > +<!ENTITY removeWarning2.label              "Als u uw hoofdwachtwoord
> > verwijdert .. uw computer wordt bedreigd">
> 
> `To expose or make liable to danger, suspicion, or disrepute: an embassy that
> was compromised by hidden listening devices.'  Juister zou dus zijn `indien uw
> computer aan gevaar wordt blootgesteld', maar dat past niet echt in de zin. 
> Misschien overgenomen? Overgedragen komt op mij actief over, wat het in dit
> geval zeker niet is.  (Vandaar mijn verandering)

Overgedragen is iig fout. Overgenomen lijkt mij ok, zeker omdat we het elders ook zo vertaald hebben.


> `U zou bijvoorbeeld aparte profielen kunnen hebben voor zakelijk en
> persoonlijk gebruik'? 

Prima.


> > Ergens jammer, want voor de filterregels was 'voldoen aan' wel een goede
> > oplossing (kan een bericht immers wel overeenkomen met een aantal criteria
> > ervoor?). Maar of overal 'Voldoend aan' nou zo'n goed idee is..
> > 
> > Ik pleit voor aparte entities.
> 
> Ik ook.

Ik heb geen idee wat aparte entities zijn, maar goed :).


~Grauw

    
    

    
  
Komende maandag (31 oktober) staat Firefox 1.5 RC1 gepland. Op dat moment moet de Nederlandse vertaling dus ook helemaal af zijn, anders is het natuurlijk geen RC. Om de Nederlandse RC snel na en-US te kunnen vrijgeven zullen we onze versies goed moeten testen. Op dit moment is daar nog geen informatie over, maar ik wil voorstellen om aanstaande vrijdag de laatste wijzigingen toe te passen. Dan hebben we het weekend om alles te testen en eventuele kritische zaken op te lossen. Houden jullie hier rekening mee zodat alles wat jullie in 1.5 willen hebben dan als patch beschikbaar is, waar iedereen het over eens is. 

Dingen die nog moeten gebeuren:
- Developer.mozilla.org toegevoegd aan bladwijzers (GP)
- Searchplugins moeten hernoemd worden en amo als update-url gebruiken (GP)
- Patch van Hendrik moet herzien worden. Ton wees me erop dat door de correctie van de accesskey en jouw patch er twee dezelfde accesskeys gebruikt gaan worden. Misschien kun je hiernaar kijken en beslissen of de accesskey van 'Homepage bezoeken' of naar de bovenkant verplaatsen, veranderd moet worden
- Breedte-wijzigingen op de Mac. Dit is nog niet helemaal goed. Hierover is correspondentie met een mac-gebruiker.

    
    

    
  
(In reply to comment #301)
> 
> Beiden zijn goed. Dus ik zou het zo laten. Vanwege betekent in Nederland
> hetzelfde als wegens. De betekenis van ergens vandaan komen lijkt me idd een
> Vlaams ding.
> 
> Ik ben het in ieder geval eens met het vervangen van door. Of het nou vanwege
> of wegens wordt maakt mij niet uit.

Zo doet 'wegens' mij wat meer denken aan gebeurtenissen die wel of niet doorgaan, en 'vanwege' beter passen bij een erop volgende oorzaak. Hoe dan ook, als we het hier 'vanwege' laten, dan misschien ook die uit https://bugzilla.mozilla.org/attachment.cgi?id=198213&action=view herstellen? (Enige 3 voorkomens, onlangs ook gewijzigd)

> Ik lees het zonder koppelteken als Pluginzoek-service. Weet niet of dat gewenst
> is.

Dat bedoelde ik..

> > > removemp.dtd
> > > -<!ENTITY removeWarning2.label              "Als u uw hoofdwachtwoord
> > > verwijdert .. uw computer wordt overgedragen.">
> > > +<!ENTITY removeWarning2.label              "Als u uw hoofdwachtwoord
> > > verwijdert .. uw computer wordt bedreigd">
> > 
> > `To expose or make liable to danger, suspicion, or disrepute: an embassy that
> > was compromised by hidden listening devices.'  Juister zou dus zijn `indien uw
> > computer aan gevaar wordt blootgesteld', maar dat past niet echt in de zin. 
> > Misschien overgenomen? Overgedragen komt op mij actief over, wat het in dit
> > geval zeker niet is.  (Vandaar mijn verandering)
> 
> Overgedragen is iig fout. Overgenomen lijkt mij ok, zeker omdat we het elders
> ook zo vertaald hebben.

Vreemd eigenlijk, qua betekenis lijkt het kwaad zich nog niet voltrokken te hebben, maar in het gebruik van het woord vaak wel. In het Engels dus.

> > `U zou bijvoorbeeld aparte profielen kunnen hebben voor zakelijk en
> > persoonlijk gebruik'? 
> 
> Prima.

Prima, of eventueel nog 'Bijvoorbeeld, als u misschien aparte profielen wilt..'

> > > Ik pleit voor aparte entities.
> > 
> > Ik ook.
> 
> Ik heb geen idee wat aparte entities zijn, maar goed :).

:) Een eigen entity voor de genoemde string met 'overeenkomen met..', die dan in het geval van filterregels zoiets kan worden als 'voldoen aan één van volgende filterregels'.

Verder zie graag wat meningen over:

- Privé-gegevens 'opruimen' of 'wissen'?
- Veiligheidscertificaat of beveiligingscertificaat?
- 'Bladwijzer voor .. maken', of 'Bladwijzer maken voor ..'?

i.v.m. nog bestaande inconsistenties.

    
    

    
  
(In reply to comment #303)
> Verder zie graag wat meningen over:
> 
> - Privé-gegevens 'opruimen' of 'wissen'?

Alhoewel opruimen een te letterlijke vertaling van Engelse ‘clean up’ lijkt, is het denk ik toch wel ok. In het subscherm staat er ‘de volgende items nu wissen’, wat correct is, maar bij privé-gegevens opruimen functie in zijn geheel genomen wis je dus niet per se alle informatie en heeft het dus wel wat weg van ‘opruimen’ (selectief weggooien).

Zou overigens wel ‘de volgende items nu wissen’ willen schrijven als ‘de volgende gegevens nu wissen’, als je dat mee zou kunnen nemen, graag.


> - Veiligheidscertificaat of beveiligingscertificaat?

De tweede.


> - 'Bladwijzer voor .. maken', of 'Bladwijzer maken voor ..'?

Geen mening.


~Grauw

    
    

    
  
(In reply to comment #301)
> (In reply to comment #295)
> > > - wanneer compatibele versies beschikbaar komen.">
> > > + wanneer compatibele versies beschikbaar worden.">
> > 
> > Je schijnt gelijk te hebben, al vind ik het raar klinken.
> 
> Beschikbaar worden vind ik inderdaad een beetje vreemd.

Nee, ik vind net beschikbaar komen raar klinken.  Iets is beschikbaar of wordt beschikbaar gesteld.  Maar blijkbaar kan iets ook beschikbaar komen, af te leiden uit de vele voorbeelden.

> Ik ben het in ieder geval eens met het vervangen van door. Of het nou vanwege
> of wegens wordt maakt mij niet uit.

Precies, vooral die door stoorde me, en dan heb ik er maar overal wegens van gemaakt.  Kan dus net zo goed overal vanwege worden.

[betreft duim <> inch]
> maar wat daar staat klopt wel. Niet de computerwereld is de uitzondering dat
> die over inch spreekt, maar juist beroepgroepen als timmermannen zijn de
> uitzondering.
 
Ok dan, jammer van het veel mooiere woord duim.


    
    

    
  
(In reply to comment #304)
> (In reply to comment #303)
> > Verder zie graag wat meningen over:
> > 
> > - Privé-gegevens 'opruimen' of 'wissen'?
> 
> Alhoewel opruimen een te letterlijke vertaling van Engelse ‘clean up’ lijkt, is
> het denk ik toch wel ok. In het subscherm staat er ‘de volgende items nu
> wissen’, wat correct is, maar bij privé-gegevens opruimen functie in zijn
> geheel genomen wis je dus niet per se alle informatie en heeft het dus wel wat
> weg van ‘opruimen’ (selectief weggooien).
> 
> Zou overigens wel ‘de volgende items nu wissen’ willen schrijven als ‘de
> volgende gegevens nu wissen’, als je dat mee zou kunnen nemen, graag.

Mee eens.
 
> > - Veiligheidscertificaat of beveiligingscertificaat?
> 
> De tweede.

Ja, dat is nu al een tijdlang overal consequent veranderd, dat moet misschien nog eens globaal gecheckt worden.

> > - 'Bladwijzer voor .. maken', of 'Bladwijzer maken voor ..'?

Hangt samen met de discussie over infinitieven voor of achter.  Ik vind het tweede mooier.


    
    

    
  


  
(In reply to comment #306)
> (In reply to comment #304)
> > (In reply to comment #303)
> > 
> > wissen’, wat correct is, maar bij privé-gegevens opruimen functie in zijn
> > geheel genomen wis je dus niet per se alle informatie en heeft het dus wel wat
> > weg van ‘opruimen’ (selectief weggooien).
> 
> Mee eens.

Ik ook.

> > > - Veiligheidscertificaat of beveiligingscertificaat?
> > 
> > De tweede.
> 
> Ja, dat is nu al een tijdlang overal consequent veranderd, dat moet misschien
> nog eens globaal gecheckt worden.

Niet overal nog, vandaar. ;)

> > > - 'Bladwijzer voor .. maken', of 'Bladwijzer maken voor ..'?
> 
> Hangt samen met de discussie over infinitieven voor of achter.  Ik vind het
> tweede mooier.

Ergens ik ook wel, maar denk toch dat het eerste passender is. Voor mijn gevoel neigt het tweede nog wat meer naar de betekenis dat voor elke pagina een aparte bladwijzer wordt gemaakt. Daarnaast is het verschil (letterlijk) eerder zichtbaar tijdens het lezen, vooral als de twee opties mogelijk zijn in een menu, en ook het werkwoord achteraan staat daarin vaak wat beter.

    
    

    
  
Comment on attachment 200875 [details] [diff] [review]
Veiligheidscertificaat-> beveiligingscertificaat

Toegepast op branch en trunk

        Attachment #200875 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 200720 [details] [diff] [review]
bookmarks.patch

Is al toegepast door Tim Maks op branch. Trunk is in en-US ook nog niet gebeurd. Dat zal later nog wel eens gebeuren.

        Attachment #200720 -
        Attachment is obsolete: true

    
    

    
  
De RC is een dag verschoven, dus wat mij betreft hebben we nu tot zaterdag de tijd (patches tot ong. 12:00). Hoewel ik natuurlijk zo vroeg mogelijk alle patches heb.

Volgensmij zijn de zaken die ik moest doen opgelost, dat betekent zaken rond bladwijzers, zoekplugins en breedtes van vensters op mac/linux.

Even 2 opmerkingen/vragen:
1. De namen van de zoekplugins moeten nu een unieke naam hebben (die de gebruiker kan zien in het zoekveld). Ik heb hier gekozen voor Google.nl, Yahoo NL, eBay.nl, Nl.Bol.com, Van Dale Woordenboek en Wikipedia NL. Dit is niet geheel consistent, maar ik vond ht bij de meeste wel het mooiste staan. Een alternatief is nog Google NL en eBay NL. Ik hoor hier graag nog jullie mening over. Dit is waarschijnlijk ook het enige wat nog mag veranderen na zaterdag, omdat ik de mening van Tim Maks ook wil horen.
2. Er zat door een slordigheid van mij nog een XML-fout in de help en deze is nu opgelost. De status van de trunk van gisteren wordt echter genomen voor het maken van rc-versies (iets wat ik gisteren ook nog niet wist). Ik ben dus bang dat we met een helpfout in de rc-versie opgescheept zitten. Ik heb Pike er al over gesproken, maar die zei dat hij waarschijnlijk niets kon doen. Gelukkig controleert niet iedereen alle helppagina's. Het is popup.xhtml, dus ook niet de drukstbezochte pagina.

    
    

    
  
(In reply to comment #310)
> Even 2 opmerkingen/vragen:
> 1. De namen van de zoekplugins moeten nu een unieke naam hebben (die de
> gebruiker kan zien in het zoekveld). Ik heb hier gekozen voor Google.nl, Yahoo
> NL, eBay.nl, Nl.Bol.com, Van Dale Woordenboek en Wikipedia NL. Dit is niet
> geheel consistent, maar ik vond ht bij de meeste wel het mooiste staan. Een
> alternatief is nog Google NL en eBay NL. Ik hoor hier graag nog jullie mening
> over. Dit is waarschijnlijk ook het enige wat nog mag veranderen na zaterdag,
> omdat ik de mening van Tim Maks ook wil horen.

Ik vind het maar stom dat we dat op een dergelijke manier moeten hernoemen. Duidelijk een architecturele beslissing die genomen is door mensen die zelf in Amerika wonen en er dus toch geen last van hebben :(.

Als je dit doet, dan moet je bij nl.Bol.com niet beginnen met een hoofdletter, dat vind ik raar.

Ik zelf ben voorstander van het ‘alternatief’.


~Grauw

    
    

    
  
p.s. ik neem aan dat het niet mogelijk is om de search plugin een andere bestandsnaam te geven, maar de string die in de browser verschijnt aan te passen?


~Grauw

    
    

    
  
Tja, het ziet er idd minder uit dus ik heb het ook liever niet. We moeten en zorgen voor een unieke bestandsnaam en voor een unieke naam die weergegeven wordt. Dat eerste vind ik te begrijpen, maar dat tweede is vervelend. Zie trouwens http://groups.google.com/group/netscape.public.mozilla.l10n/browse_thread/thread/32239ec8b8ade695/ voor meer informatie.

Het probleem is dat ik een beetje met consistentie zit. Ik wil wel achter alles NL zitten, maar dan wijkt bol.com weer af. Dat zou dan Bol.com NL kunnen worden. Dat lijkt me nu het beste. Mee eens?

    
    

    
  
(In reply to comment #313)
> Dat lijkt me nu het beste. Mee eens?

Ja.


~Grauw

    
    

    
  
(In reply to comment #313)
> Ik wil wel achter alles
> NL zitten, maar dan wijkt bol.com weer af. Dat zou dan Bol.com NL kunnen
> worden. Dat lijkt me nu het beste. Mee eens?

ik vind dit ook de beste oplossing,

groet vanuit het zeer zonnige antwerpen (waar ik aan het werk ben tot en met vrijdagnacht)


    
    

    
  
(In reply to comment #313)
> Tja, het ziet er idd minder uit dus ik heb het ook liever niet. We moeten en
> zorgen voor een unieke bestandsnaam en voor een unieke naam die weergegeven
> wordt. Dat eerste vind ik te begrijpen, maar dat tweede is vervelend. Zie
> trouwens
> http://groups.google.com/group/netscape.public.mozilla.l10n/browse_thread/thread/32239ec8b8ade695/
> voor meer informatie.

Je kan het weer terug draaien naar wat het oorspronkelijk was. Ik quote:

"I'm reading that this thing is not well accepted. Anyway, my use case doesn't hold that high, as langpacks don't include search plugins right now.

So I'll drop that requirement, name the search plugins as you consider it convenient. Though I still think that non-ambiguous names have their benefit in general."

Dit antwoord van Axel is nog niet op Google Groups, maar daar zou het wel binnenkort moeten verschijnen.


~Grauw

    
    

    
  

      
      
      
      

        Attached patch
          
          
        controleren op updates (obsolete)
        — 
          — Splinter Review
      

    


  
controleren op updates aangepast in de menu's

    
    

    
  

      
      
      
      

        Attached patch
          
          
        U heeft -> u hebt (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 201124 [details] [diff] [review]
controleren op updates

toegepast op branch en trunk

Ik heb alleen wel 'Op updates controleren... 'gebruikt, zoals je een aantal dagen geleden als suggestie deed.

Ik neem aan dat dit onbedoeld hier niet gebruikt is. Als het wel een reden had, dan moet je het maar melden en draai ik mij wijzigingen terug.

        Attachment #201124 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 201144 [details] [diff] [review]
U heeft -> u hebt

toegepast op branch en trunk. Op de branch zonder problemen. Op de trunk met wat hunks. Hiermee moeten we opletten, omdat we uiteindelijk met de trunk doormoeten.

patching file nl/mail/chrome/messenger/imapMsgs.properties
Hunk #2 FAILED at 409.
Hunk #3 FAILED at 430.
2 out of 3 hunks FAILED -- saving rejects to file nl/mail/chrome/messenger/imapM
sgs.properties.rej
patching file nl/mail/chrome/messenger/localMsgs.properties
Hunk #1 succeeded at 99 (offset 12 lines).
Hunk #2 succeeded at 152 (offset 12 lines).
Hunk #3 succeeded at 192 (offset 12 lines).
Hunk #4 succeeded at 228 (offset 12 lines).
patching file nl/mail/chrome/messenger/messenger.properties
patching file nl/mail/chrome/messenger/msgSynchronize.dtd
patching file nl/mail/chrome/messenger/msgmdn.properties
patching file nl/mail/chrome/messenger/prefs.properties
patching file nl/mail/chrome/messenger/messengercompose/askSendFormat.dtd
patching file nl/mail/chrome/messenger/messengercompose/composeMsgs.properties
Hunk #1 FAILED at 163.
Hunk #2 FAILED at 184.
Hunk #3 FAILED at 239.
Hunk #4 succeeded at 190 with fuzz 1 (offset -79 lines).
3 out of 4 hunks FAILED -- saving rejects to file nl/mail/chrome/messenger/messe
ngercompose/composeMsgs.properties.rej

        Attachment #201144 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 200475 [details] [diff] [review]
nog maar eens toolkit

Hendrik: Wat wil je nog met de patch die hierboven open staan. Er was wat commentaar op, dus als je wilt dat dingen nog toegepast worden graag een nieuwe patch. Ik markeer deze nu als obsolete.

De zoekplugins zijn nu ook terugveranderd zonder .nl of NL. Dat is dus ook weer goed.

        Attachment #200475 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #319)
> (From update of attachment 201124 [details] [diff] [review] [edit])
> toegepast op branch en trunk
> 
> Ik heb alleen wel 'Op updates controleren... 'gebruikt, zoals je een aantal
> dagen geleden als suggestie deed.

Ondanks mijn gepleit voor infinitief achteraan hierboven vond ik 'Controleren op updates' in het menu, maar ook in de Help, op 1 of andere manier beter staan. Komt denk ik door 'Op up..', en de vele overige voorkomens van 'Controleren op updates' die er nog zijn. Daarbij is het ook niet echt een gebruikeractie, dus wat mij betreft mag het wel terug. Ik begreep dat Gert-Paul ook zo zijn bedenkingen had, graag nog mening van anderen.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Nog een paar kleinigheden (obsolete)
        — 
          — Splinter Review
      

    


  
Items->gegevens, (beschikbaar) wordt -> komt, figuren > afbeeldingen en paar keer 'rood/groen'.

    
    

    
  
Comment on attachment 201190 [details] [diff] [review]
Nog een paar kleinigheden

toegepast op branch en trunk

        Attachment #201190 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        5 strings voor extensie/herstart (obsolete)
        — 
          — Splinter Review
      

    


  
Het eerdere pleonasme in deze strings was er al uit, maar dit is in het Engels iets anders hersteld (rev. 1.18, bug 300895). Patch wijzigt naar originele vertaling. Of ie mooi genoeg is laat ik aan anderen over, wat mij betreft mag ie wel, vooral daar het taalkundig ook wat kloppender is.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Review att 198213 (obsolete)
        — 
          — Splinter Review
      

    


  
Min of meer een kritische kijk; sommige dingen verder aangepast, andere teruggezet om wat ik denk legitieme redenen.

Viel me nog op dat 'versturen' in 'Bestand' een dubbele access key heeft. Misschien een u van maken? (Waarom overigens niet 'Verzenden' en de z?)

Ik zie verder sinds een paar dagen 'Report broken website' bovenin bij Help i.p.v. in het Nederlands. Heeft dat iets met een lokaal missend chrome-bestand te maken of is er echt iets mis mee?

En.. moesten de 'stopknop', 'vooruitknop' etc. in de Help niet ook 'Knop ..' zijn?

    
    

    
  
Comment on attachment 201218 [details] [diff] [review]
5 strings voor extensie/herstart

toegepast op branch en trunk

        Attachment #201218 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 201234 [details] [diff] [review]
Review att 198213

toegepast op branch en trunk

        Attachment #201234 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #326)
> Viel me nog op dat 'versturen' in 'Bestand' een dubbele access key heeft.
> Misschien een u van maken? (Waarom overigens niet 'Verzenden' en de z?)
Ik vind versturen mooier, dat heeft dan ook mij voorkeur. De K is volgensmij ook nog vrij, dus die kunnen we hier ook gebruiken.
> Ik zie verder sinds een paar dagen 'Report broken website' bovenin bij Help
> i.p.v. in het Nederlands. Heeft dat iets met een lokaal missend chrome-bestand
> te maken of is er echt iets mis mee?
Een tijdje geleden is er wel wat veranderd aan de manier waarop dat meegeleverd werd. Misschien dat je daar problemen mee hebt? Heb je de hele installatiemap leeggemaakt en de meest recente nightly (bv uit de map met 1.5rc candidates) gehaald?
> En.. moesten de 'stopknop', 'vooruitknop' etc. in de Help niet ook 'Knop ..'
> zijn?
Waar is het dan nog niet goed? In de index-klopt het niet, maar daar kan iets als 'knop vernieuwen' ook anders opgevat worden. Ik vind het daar (zonder context) misschien wel beter om ..knop te gebruiken, hoewel ik met het andere geen problemen heb. Wat is de mening van de anderen hierover?

    
    

    
  
Wat laatste veranderingen:
Op updates controleren -> Controleren (Ton, Tim Maks en ik vonden dit beter)
gegevens wordt nu ook gebruikt in Opties > Privacy > Instellingen (en een infinitief wordt gebruikt)
..knop is veranderd in knop .. in de helpindex.

Zie bonsai voor de preciese veranderingen.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Att 200475 incl. commentaar (obsolete)
        — 
          — Splinter Review
      

    


  
Met commentaar verwerkt.

Verschil met die van Hendrik / niet toegepast:
printPageSetup
xpinstall.properties (alleen 2 laatste wijzigingen wel)
region.properties
extensions.prop: meeste wel, alleen de groottewijzigingen niet omdat ik niet zeker weet of dat juist is.

Kan nog iets vergeten zijn.

    
    

    
  
Comment on attachment 201273 [details] [diff] [review]
Att 200475 incl. commentaar

toegepast op branch en trunk, inclusief pluginslicenties (zonder -).

        Attachment #201273 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #323)
> Created an attachment (id=201190) [edit]
> Nog een paar kleinigheden
> 
> Items->gegevens, (beschikbaar) wordt -> komt, figuren > afbeeldingen en paar
> keer 'rood/groen'.

+filterListBackUpMsg=Uw filters werken niet omdat het bestand msgFilterRules.dat, dat uw filters bevat, niet kon worden gelezen. Er zal een nieuw msgFilterRules.dat-bestand worden gemaakt en een backup van het oude bestand, genaamd rulesbackup.dat, zal worden gemaakt in dezelfde directory.
directory -> map (als we dan toch bezig zijn...)

+load-js-data-url-error=Om beveiligingsredenen kunnen javascript- of data-url\u2019s niet vanuit de geschiedenis of zijbalk worden geladen.
Kan dit niet beter iets als ‘Omwille van de veiligheid...’ worden?

(In reply to comment #326)
> Created an attachment (id=201234) [edit]
> Review att 198213
> 
> Min of meer een kritische kijk; sommige dingen verder aangepast, andere
> teruggezet om wat ik denk legitieme redenen.

Ik zie geen reden om ‘responder’ te gebruiken, maar misschien ben ik niet genoeg van de terminologie op de hoogte?

-CertDumpEmailCA=E-mailcertificatieautoriteit
+CertDumpEmailCA=E-mail certificatieautoriteit
Waarom dat?  Het is toch een autoriteit voor e-mailcertificaten, en niet de e-mail van de certificatieautoriteit, of begrijp ik het hier verkeerd?

+<!ENTITY loaddevice.modname.default "Nieuwe PKCS #11-module">
Staat in het Engels ook aaneen.  Er schijnt geen logica in te zitten.
-file_browse_PKCS12_spec=PKCS#12-bestanden
+file_browse_PKCS12_spec=PKCS #12-bestanden
idem

-pageInfo_Privacy_Strong1=De pagina die u bekijkt was beveiligd voordat zij over het internet werd verzonden.
+pageInfo_Privacy_Strong1=De pagina die u bekijkt was beveiligd voordat hij over het internet werd verzonden.
Pagina is toch echt wel vrouwelijk hoor, maar bon, ik leg me erbij neer dat er in het noordelijk Nederlands geen geslachten meer bestaan.

(In reply to comment #331)
> Created an attachment (id=201273) [edit]
> Att 200475 incl. commentaar
> 
> Met commentaar verwerkt.

Bedankt!  Ziet er goed uit, ik kan hiermee leven, behalve:

-error-261=Ongeldige bestand hash (mogelijke downloadcorruptie)
-error-262=Onbekend of ongeldige bestand hashtype
+error-261=Ongeldige bestandhash (mogelijke downloadcorruptie)
+error-262=Onbekend of ongeldige bestandhashtype
Tweede keer moet ongeldig zijn, en ik zou een s tussen bestand en hash zetten (maar ook hier is bekend dat dit N/Z nogal verschilt)

+<!ENTITY profileCreationExplanation_3.text "Als u de enige bent die deze kopie van &brandShortName; gebruikt, moet u minstens één profiel hebben. U kunt, als u wilt, meerdere profielen aanmaken voor uzelf om verschillende sets van instellingen en voorkeuren op te slaan. U zou bijvoorbeeld aparte profielen kunnen hebben voor zakelijk en persoonlijk
+gebruik.">
Ik denk niet dat het de bedoeling is dat dit over twee lijnen staat (hoewel het waarschijnlijk geen kwaad kan?)

-<!ENTITY  state.header              "Status">
+<!ENTITY  state.header              "Staat">
Ik kan me niet herinneren dat ik dit voorgesteld heb, vind het in ieder geval geen goed idee.

    
    

    
  
(In reply to comment #333)
> +load-js-data-url-error=Om beveiligingsredenen kunnen javascript- of
> data-url\u2019s niet vanuit de geschiedenis of zijbalk worden geladen.
> Kan dit niet beter iets als ‘Omwille van de veiligheid...’ worden?

Ik zou het zo laten, of om -> vanwege / wegens.


> -CertDumpEmailCA=E-mailcertificatieautoriteit
> +CertDumpEmailCA=E-mail certificatieautoriteit
> Waarom dat?  Het is toch een autoriteit voor e-mailcertificaten, en niet de
> e-mail van de certificatieautoriteit, of begrijp ik het hier verkeerd?

Lijkt mij ook ja...


> -pageInfo_Privacy_Strong1=De pagina die u bekijkt was beveiligd voordat zij
> over het internet werd verzonden.
> +pageInfo_Privacy_Strong1=De pagina die u bekijkt was beveiligd voordat hij
> over het internet werd verzonden.
> Pagina is toch echt wel vrouwelijk hoor, maar bon, ik leg me erbij neer dat er
> in het noordelijk Nederlands geen geslachten meer bestaan.

Op zich vind ik niks mis met ‘zij’ te lezen (in ieder in dit geval), maar het probleem is dat wij als noordelijk-Nederlanders er geen onderscheid meer tussen kunnen maken, en het dus lastig wordt om dingen consistent te blijven veralen.


> -error-261=Ongeldige bestand hash (mogelijke downloadcorruptie)
> -error-262=Onbekend of ongeldige bestand hashtype
> +error-261=Ongeldige bestandhash (mogelijke downloadcorruptie)
> +error-262=Onbekend of ongeldige bestandhashtype
> Tweede keer moet ongeldig zijn, en ik zou een s tussen bestand en hash zetten
> (maar ook hier is bekend dat dit N/Z nogal verschilt)

Bestandshash (met tussen-s) lijkt mij ook beter.


~Grauw

    
    

    
  
(In reply to comment #333)
> directory -> map (als we dan toch bezig zijn...)
In Thunderbird komt volgensmij nog vaker directory voor, maar daar is het nu echt te laat voor imo. We moeten dit dan consistent in mail/editor doorvoeren. Lijkt me eerder iets voor de trunk, zeker aangezien we vandaag de branch wilden bevriezen. Ik wil alleen wel graag de zaken die net aangedragen zijn nog even afhandelen.
 
> -CertDumpEmailCA=E-mailcertificatieautoriteit
> +CertDumpEmailCA=E-mail certificatieautoriteit
> Waarom dat?  Het is toch een autoriteit voor e-mailcertificaten, en niet de
> e-mail van de certificatieautoriteit, of begrijp ik het hier verkeerd?
In zulk soort dingen ben ik geen kei, maar ik heb hier misschien overheen gekeken. Ik wacht nog even op een reactie van Ton, maar als twee personen er een opmerking over maken zal ik het waarschijnlijk terugdraaien.
> +<!ENTITY loaddevice.modname.default "Nieuwe PKCS #11-module">
> Staat in het Engels ook aaneen.  Er schijnt geen logica in te zitten.
> -file_browse_PKCS12_spec=PKCS#12-bestanden
> +file_browse_PKCS12_spec=PKCS #12-bestanden
> idem
Ik had het Engels niet gecontroleerd hier, maar als het daar ook aan elkaar is moeten we dat waarschijnlijk zo laten. Of Ton moet hier een goede reden voor hebben.

> -error-261=Ongeldige bestand hash (mogelijke downloadcorruptie)
> -error-262=Onbekend of ongeldige bestand hashtype
> +error-261=Ongeldige bestandhash (mogelijke downloadcorruptie)
> +error-262=Onbekend of ongeldige bestandhashtype
> Tweede keer moet ongeldig zijn, en ik zou een s tussen bestand en hash zetten
> (maar ook hier is bekend dat dit N/Z nogal verschilt)
Ik ben het een met de wijzigingen die jullie hier voorstellen. Dit pas ik zo nog toe.
> 
> +<!ENTITY profileCreationExplanation_3.text "Als u de enige bent die deze kopie
> van &brandShortName; gebruikt, moet u minstens één profiel hebben. U kunt,
> als u wilt, meerdere profielen aanmaken voor uzelf om verschillende sets van
> instellingen en voorkeuren op te slaan. U zou bijvoorbeeld aparte profielen
> kunnen hebben voor zakelijk en persoonlijk
> +gebruik.">
> Ik denk niet dat het de bedoeling is dat dit over twee lijnen staat (hoewel het
> waarschijnlijk geen kwaad kan?)
Hoort idd niet. Het moet geen kwaad kunnen, maar ook dat zal ik terugveranderen.

> -<!ENTITY  state.header              "Status">
> +<!ENTITY  state.header              "Staat">
> Ik kan me niet herinneren dat ik dit voorgesteld heb, vind het in ieder geval
> geen goed idee.
Ik had er ook mijn twijfels over, maar opzich is state wel wat anders dan status. Dat laatste hebben we natuurlijk status gelaten, maar state is wel wat anders. Ton verwees me ook door naar commentaar van Laurens: https://bugzilla.mozilla.org/show_bug.cgi?id=291678#c155

    
    

    
  
(In reply to comment #333)
> 
> +filterListBackUpMsg=Uw filters werken niet omdat het bestand
> msgFilterRules.dat, dat uw filters bevat, niet kon worden gelezen. Er zal een
> nieuw msgFilterRules.dat-bestand worden gemaakt en een backup van het oude
> bestand, genaamd rulesbackup.dat, zal worden gemaakt in dezelfde directory.
> directory -> map (als we dan toch bezig zijn...)

Je zou zeggen dat 'map' juist is en dat het in het Engels 'folder' had moeten zijn daar 'directory' meer wordt gebruikt voor directory servers e.d. Ik geloof echter dat voor systeemfolders (dus op bestandsniveau) met opzet ook overal 'directory' wordt gebruikt, en met 'map' bv. de in TB zichtbare of virtuele mappen voor mail etc., of een bookmarks folder in FF. In het Engels is hier dan terecht directory gebruikt en daarom ook in het Nederlands, tenzij we deze begrippen in beide gevallen mappen willen noemen maar dat lijkt me niet de bedoeling. Tegen dergelijke 'Mac-termen' bestaat bij menig Windows-gebruiker nog steeds bezwaar en onder Linux/Unix is dit meen ik al helemaal uit den boze, maar dat staat er eigenlijk los van.

> +load-js-data-url-error=Om beveiligingsredenen kunnen javascript- of
> data-url\u2019s niet vanuit de geschiedenis of zijbalk worden geladen.
> Kan dit niet beter iets als ‘Omwille van de veiligheid...’ worden?

Lijkt me wat formeel, maar 'Vanwege' zou misschien wel iets beter staan.

> (In reply to comment #326)
> 
> Ik zie geen reden om ‘responder’ te gebruiken, maar misschien ben ik niet
> genoeg van de terminologie op de hoogte?

Ik weet er ook niet alles van maar denk wel dat statusbeantwoorder wat te letterlijk is vertaald en statusresponder hier de algemeen gehanteerde term is (er is niks vreemds aan een responder). Zelfs in twijfelgevallen, of liever gezegd gevallen waarin we nog geen echte Nederlandse vertaling hebben, is het volgens mij de gewoonte om voor een woord, al dan niet voor een gedeelte van een samenstelling bij het Engels te blijven. Althans in NL; wellicht dat het Vlaams dit juist niet doet?

> -CertDumpEmailCA=E-mailcertificatieautoriteit
> +CertDumpEmailCA=E-mail certificatieautoriteit
> Waarom dat?  Het is toch een autoriteit voor e-mailcertificaten, en niet de
> e-mail van de certificatieautoriteit, of begrijp ik het hier verkeerd?

Ik dacht inderdaad het laatste, omdat een e-mail(-)certificatieautoriteit (wat een certificatieautoriteit lijkt te zijn voor e-mail) volgens mij niet bestaat. Vandaar de aanname dat het gaat om de e-mail (=het adres) van de certificatieautoriteit, maar ook vanwege de Duitse vertaling (Der Zertifizierungsstelle mitteilen), hoewel men e-mail daarin als actie ziet, als in 'certificatieautoriteit e-mailen'.

De Franse vertaling echter heeft het over een 'Autorité de certification de courrier' en de Italiaanse en Spaanse iets vergelijkbaars, wat duidt op de andere betekenis. Daarbij zou er waarschijnlijk ook wel iets met 'address' hebben gestaan als het inderdaad om een e-mailadres ging. Maar... dan zal de juiste term waarschijnlijk 'E-mailcertificaatautoriteit' zijn, wat inderdaad een autoriteit moet zijn voor e-mailcertificaten, en om verdere verwarring met 'certificatieautoriteit' tegen te gaan eventueel 'E-mailcertificaat-autoriteit'?

> +<!ENTITY loaddevice.modname.default "Nieuwe PKCS #11-module">
> Staat in het Engels ook aaneen.  Er schijnt geen logica in te zitten.
> -file_browse_PKCS12_spec=PKCS#12-bestanden
> +file_browse_PKCS12_spec=PKCS #12-bestanden
> idem

Er is geen logica, behalve dat PKCS-termen v.z.i.w. altijd met spatie worden geschreven en dit blijkbaar in enkele gevallen in FF niet is aangehouden, vermoedelijk per abuis. Dacht er dus goed aan te doen dit wel te doen, ook al zou het niet kloppen met de Engelse tekst. Nu ik er zo over nadenk, Gert-Paul heeft onlangs een foutlog gepost waarin als ik me niet vergis vanwege een dergelijk geval iets van een incompatibiliteit werd gemeld en 1 van de voorkomens van PKCS had hij daarom meen ik aangepast. Misschien dat dat dus weer zou gebeuren als er spaties staan maar als het mogelijk is zou ik die fout negeren en toch in alle voorkomens een spatie zetten.
N.B. één van de twee is nu teruggezet in deviceManager.dtd.

> -pageInfo_Privacy_Strong1=De pagina die u bekijkt was beveiligd voordat zij
> over het internet werd verzonden.
> +pageInfo_Privacy_Strong1=De pagina die u bekijkt was beveiligd voordat hij
> over het internet werd verzonden.
> Pagina is toch echt wel vrouwelijk hoor, maar bon, ik leg me erbij neer dat er
> in het noordelijk Nederlands geen geslachten meer bestaan.

Inderdaad, ik twijfel daar niet zozeer aan (alhoewel ik het bewijs niet eens kon vinden, om maar even aan te geven wat een moeite dit kan kosten) maar denk toch dat dit het verstandigst is. Het grootste deel van de Nederlanders slaat 'hem' nu eenmaal om als het om de pagina gaat. Om dezelfde reden lijkt het me ook beter om 'zij' in MediaDocument.properties - InvalidImage ('De afbeelding .. omdat ze fouten bevat.') ook terug te wijzigen naar 'hij', ondanks de eerdere discussie. Het is zoals Laurens zegt inderdaad te lastig om dit bij te houden, maar ondanks de correctheid bovenal te ongewoon, hoe raar het ook mag klinken.

> (In reply to comment #331)
> 
> -error-261=Ongeldige bestand hash (mogelijke downloadcorruptie)
> -error-262=Onbekend of ongeldige bestand hashtype
> +error-261=Ongeldige bestandhash (mogelijke downloadcorruptie)
> +error-262=Onbekend of ongeldige bestandhashtype
> Tweede keer moet ongeldig zijn, en ik zou een s tussen bestand en hash zetten
> (maar ook hier is bekend dat dit N/Z nogal verschilt)

Klopt, 2e keer 'ongeldig' over het hoofd gezien, de s heb ik nog even geplaatst maar meteen weer weggehaald omdat jij hem ook niet voorstelde en ik dacht dat je daar een goede reden voor had. Ik zou ze er wel in zetten.
N.B.: er mist nu nog een s (262).

> kunnen hebben voor zakelijk en persoonlijk
> +gebruik.">
> Ik denk niet dat het de bedoeling is dat dit over twee lijnen staat (hoewel het
> waarschijnlijk geen kwaad kan?)

Klopt, foutje a.g.v. copy/paste en een beetje haast. :)

> -<!ENTITY  state.header              "Status">
> +<!ENTITY  state.header              "Staat">
> Ik kan me niet herinneren dat ik dit voorgesteld heb, vind het in ieder geval
> geen goed idee.

Is eerder besproken en hopelijk ok, zie hierboven.

Nog even over 8-bits e.d.: termen met '8-bits' (met s) krijgen volgens mij i.i.g. een spatie (evenals in pref-ssl.dtd), en '8-bittekens' zou op zich goed gerekend kunnen worden, ware het niet dat dit dan een vrij nieuw woord zou zijn. '8-bits-ascii-karakter' is daarom zeer discutabel..

    
    

    
  
Comment on attachment 201316 [details] [diff] [review]
Correcties n.a.v. att 201273

toegepast op branch en trunk

        Attachment #201316 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties n.a.v. att 201273 (obsolete)
        — 
          — Splinter Review
      

    


  
Weet niet of het nog mee kan maar dit 'fixt' de bovengenoemde resterende zaken, dus 2xPKCS, bestandshash, E-mailcertificaatautoriteit en Vanwege.

Verder nog een grote V voor de Help (ja, die..) en 'Opties voor popupblokkering'  -> 'Popupblokkeringsopties' in FF zelf, met een paar verwante strings en keys.

    
    

    
  
De branch is nu gesloten. We gaan weer verder in de trunk, zie hiervoor 289795.

fouten die opgelost moeten worden voor de eind versie van Fx en Tb 1.5 kunnen gemeld worden in bug 314390
Blocks: 289795
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED

    
    

    
  
(In reply to comment #336)
> Je zou zeggen dat 'map' juist is en dat het in het Engels 'folder' had moeten
> zijn daar 'directory' meer wordt gebruikt voor directory servers e.d. Ik geloof
> echter dat voor systeemfolders (dus op bestandsniveau) met opzet ook overal
> 'directory' wordt gebruikt, en met 'map' bv. de in TB zichtbare of virtuele
> mappen voor mail etc., of een bookmarks folder in FF. In het Engels is hier dan
> terecht directory gebruikt en daarom ook in het Nederlands, tenzij we deze
> begrippen in beide gevallen mappen willen noemen maar dat lijkt me niet de
> bedoeling. Tegen dergelijke 'Mac-termen' bestaat bij menig Windows-gebruiker
> nog steeds bezwaar en onder Linux/Unix is dit meen ik al helemaal uit den boze,
> maar dat staat er eigenlijk los van.

Er, het is geen Mac/Linux term.

Directory is van oudsher de naam geweest voor een ‘map’ in vele besturingssystemen zoals alle DOS en CP/M varianten.

Vanaf als ik me niet vergis de introductie van Windows 95 gebruikte het besturingssysteem echter de term ‘map’ (folder). Ook in andere besturingssystemen gebeurt dit. Alhoewel de term directory het nog heel lang heeft volgehouden en er nog veel mensen zijn die hem gebruiken, heeft ‘folder’ onderhand toch wel de overhand verkregen.

Van Wikipedia (http://en.wikipedia.org/wiki/Directory):

"The name folder, presenting an analogy to the file folder used in offices, is common on some operating systems such as Mac OS and, increasingly, Microsoft Windows.

Strictly speaking, there is a difference between a directory which is a filing system concept, and the WIMP metaphor that is used to represent it (a folder)."

Voor onze vertaling is het vrij simpel en daar hoeven we verder niet zoveel over na te denken: als er in het Engels ‘directory’ staat, dan moeten wij als ‘directory’ vertalen, en als er ‘folder’ staat dan moeten wij vertalen als ‘map’. Op die manier laten wij een eventueel verschil in terminologie intact.


> > Pagina is toch echt wel vrouwelijk hoor, maar bon, ik leg me erbij neer dat
> > er in het noordelijk Nederlands geen geslachten meer bestaan.
> 
> Inderdaad, ik twijfel daar niet zozeer aan (alhoewel ik het bewijs niet eens
> kon vinden, om maar even aan te geven wat een moeite dit kan kosten)

Je zal er een woordenboek of het groene boekje op na moeten slaan, zou ik zeggen...

> maar ondanks de correctheid bovenal te ongewoon, hoe raar het ook mag
> klinken.

Yeah...


~Grauw

    
    

    
  
(In reply to comment #340)
> Voor onze vertaling is het vrij simpel en daar hoeven we verder niet zoveel
> over na te denken: als er in het Engels ‘directory’ staat, dan moeten wij als
> ‘directory’ vertalen, en als er ‘folder’ staat dan moeten wij vertalen als
> ‘map’. Op die manier laten wij een eventueel verschil in terminologie intact.

Ok.

> > > Pagina is toch echt wel vrouwelijk hoor, maar bon, ik leg me erbij neer dat
> > > er in het noordelijk Nederlands geen geslachten meer bestaan.
> > 
> > Inderdaad, ik twijfel daar niet zozeer aan (alhoewel ik het bewijs niet eens
> > kon vinden, om maar even aan te geven wat een moeite dit kan kosten)
> 
> Je zal er een woordenboek of het groene boekje op na moeten slaan, zou ik
> zeggen...

Of gewoon Vlaams leren... (den boom: m, de wolk: v)


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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: