Closed Bug 289795 Opened 19 years ago Closed 16 years ago

nl-NL trunk

Categories

(Mozilla Localizations :: nl / Dutch, defect)

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

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: mad_maks, Assigned: mad_maks)

References

Details

Attachments

(69 obsolete files) 

I have moved almost all the files to the new l10n structure, these files still
has to be replaced by the nl-NL versions from the branch. please attach the
right files as a patch to this bug.

- All the files in security/manager/chrome/Pippki 
- All the files in extensions/reporter/chrome (these are new files and need to
be translated)

see for the files:
http://lxr.mozilla.org/l10n/source/nl-NL/
Yesterday I started looking at these reporter files and if I'm ready I will
attach them together with my revised patch. This will hopefully be at the end of
this week.

Some more things to do:
- Translate new pref-dialog. This uses the preferences directory inside
http://lxr.mozilla.org/l10n/source/nl-NL/browser/chrome/browser/, instead of
pref-directory.
- security/manager/chrome/Pippki/pipnss/
- accessibility/, security/, webservices/, xml/ in dom/chrome/
- Files in other-licenses/
please make the patch against the latest version in the cvs and not against your
local copy (i am just saying this as a warning. the files change everyday!
All Toolkits files are in sync with the en-US trunk except:

./chrome/global/contentAreaCommands.properties
./chrome/global/findbar.properties
./chrome/global/preferences.dtd
./chrome/global/findbar.dtd
./chrome/mozapps/preferences
./chrome/autoconfig
./chrome/cookie

these files needed to be translated
All Netwerk files are in sync with the en-US trunk.
All Dom files are in sync with the en-US trunk except:
./chrome/layout/xmlparser.properties
./chrome/webservices
./chrome/accessibility
./chrome/xml
./chrome/security

./chrome/layout/css.properties (englisch version present)

Browser is in sync:

./chrome/browser/preferences/changeaction.dtd
./chrome/browser/preferences/colors.dtd
./chrome/browser/preferences/connection.dtd
./chrome/browser/preferences/content.dtd
./chrome/browser/preferences/cookies.dtd
./chrome/browser/preferences/downloadactions.dtd
./chrome/browser/preferences/downloads.dtd
./chrome/browser/preferences/general.dtd
./chrome/browser/preferences/permissions.dtd
./chrome/browser/preferences/preferences.properties
./chrome/browser/preferences/privacy.dtd
still need to be translated
Do we want make that 'nl' instead of 'nl-NL'? I'm ok with 'nl-NL' myself, but we
could change it...

By the way, is this also the bug patches can be attached too? Perhaps when we
make some first build we could put it online somewhere to get feedback. So we
can have a pretty solid build when 1.1 becomes final.
OS: Windows 2000 → All
Hardware: PC → All
(In reply to comment #7)
> Do we want make that 'nl' instead of 'nl-NL'? I'm ok with 'nl-NL' myself, but we
> could change it...
> 
> By the way, is this also the bug patches can be attached too? Perhaps when we
> make some first build we could put it online somewhere to get feedback. So we
> can have a pretty solid build when 1.1 becomes final.

if this was the first chek in i would made it nl but it was allready in the cvs
before this was allowed. So let keep it nl-NL.

patches can be attached in this bug, i hope to have a langpack (or automatic
build) soon. Please help me with replacing the files mention above. They have
moved so mutch files and strings that it took me allready days to get all files
into the right dir.
This is the patch. I also translated some of the preferences files based on the
1.0 translation. I translated the new word Sanitize into 'Opruimen', but I
don't know what you have in mind. I also found the translated word
'Bladergeschiedenis'. For 1.0 we replaced Bladeren with Navigeren, so do we
have to make this 'Navigatiegeschiedenis'?

I noticed not all files are in the nl-NL-directory. Tim Maks, could you look at
these files:
nl-NL/toolkit/chrome/autoconfig
nl-NL/toolkit/chrome/global/contentAreaCommands.properties
nl-NL/toolkit/chrome/global/findbar.dtd
nl-NL/toolkit/chrome/global/findbar.properties
nl-NL/toolkit/chrome/global/preferences.dtd
I already translated them so I can send them to you. They are not included in
my patch.
Comment on attachment 180947 [details] [diff] [review]
Promised patch with lots of improvements

patch is applied
Attachment #180947 - Attachment is obsolete: true
(In reply to comment #3)
> All Toolkits files are in sync with the en-US trunk except:
> 
> ./chrome/global/contentAreaCommands.properties
> ./chrome/global/findbar.properties
> ./chrome/global/preferences.dtd
> ./chrome/global/findbar.dtd
> ./chrome/mozapps/preferences
> ./chrome/autoconfig
> ./chrome/cookie
> 
> these files needed to be translated


all toolkit files are in the trunk now, only the files in
./chrome/mozapps/preferences still needed to be translated.
The trunk is moved to nl

http://lxr.mozilla.org/l10n/source/nl/

use these dir for your patches from now on!
(In reply to comment #0)
> I have moved almost all the files to the new l10n structure, these files still
> has to be replaced by the nl-NL versions from the branch. please attach the
> right files as a patch to this bug.
> 
> - All the files in security/manager/chrome/Pippki 
> - All the files in extensions/reporter/chrome (these are new files and need to
> be translated)
> 
> see for the files:
> http://lxr.mozilla.org/l10n/source/nl-NL/

zijn vertaald door Gert-Paul, bedankt
I have found some errors in the buildprocess and fixed them. As everything goes
allright there will be a linuxbuild tonight. I have opened a new bug for users
to commit there patches (let's speak dutch in that bug).

when the first builds are on the ftp server i will send a email to the list and
all the volunteers with a test request.

MM
Depends on: 291678
Depends on: 293223
Depends on: 297896
(In reply to comment #14)
> I have found some errors in the buildprocess and fixed them. As everything goes
> allright there will be a linuxbuild tonight. I have opened a new bug for users
> to commit there patches (let's speak dutch in that bug).

That is bug 291678, continued in bug 297896 (in case anyone looks for them...)

The work for the Tb en Tx 1.5 branch will be continued in bug 305315
Issues with Tb or Fx 1.5 RC 1 can be reported in bug 314390. In this bug we are going to work on the trunk again.
Status: NEW → ASSIGNED
Depends on: 314390
Depends on: 305315
Depends on: 314496
A lot of improvements for our current translation. This patch is made from the branch, but should work on the trunk too (only 1 files gives problems). I can fix that manually.

Some things of this patch (region.properties files) also need to land on the branch imo. Other things would be nice too, but are not necessary. Shall we ask approval for this patch, so that our translation for 1.5 can be better and more consistent. We use e.g. Herhalen in some Thunderbird menu's, while other TB menu's en Firefox use Opnieuw uivoeren. Tonnes also did some work for the accesskeys. 
The patch has become rather big, so I don't know how much time it will take to review.
Is dit niet iets voor bug 314390 dan?

Ok, ik heb de patch doorgelezen, mijn opmerkingen:

Ik snap de wijziging van recent -> recentelijk niet helemaal, beiden zijn goed lijkt mij. Maar goed, het is mij om het even.


>-fallbackDefaultSearchURL=http://www.google.nl/search?&q=
>+fallbackDefaultSearchURL=http://nl.start.mozilla.com/firefox

Dit lijkt mij niet goed. Er wordt een zoekterm achter geconcatenate. Staat ook zo in het Engels. Niet wijzigen dus.


>-browser.startup.homepage=http://start.mozilla.org/firefox/
>+browser.startup.homepage=http://nl.start.mozilla.com/firefox

Als ik naar http://nl.start.mozilla.com/firefox ga, dan krijg ik een Engelse pagina. Dat geldt overigens ook voor de vorige URL. Als ik naar http://www.google.nl/firefox ga, dan is het Nederlands.

Draagt iemand er zorg voor dat nl.start.mozilla.com naar Google.nl wordt doorverwezen?


>-<!ENTITY findAgainCmd.label "Volgende zoeken">
>+<!ENTITY findAgainCmd.label "Opnieuw zoeken">

Is de access key hier ook veranderd naar w?


>+4015=Het LIST-commando had geen succes. Fout bij verkrijgen van het ID en formaat van een bericht.
>+4024=Het STAT-commando had geen succes. Fout bij verkrijgen van berichtnummers en -formaten.

‘had geen succes’ -> ‘was niet succesvol’

(we gebruiken elders ook succesvol, en het is mooier)


>+filterFolderDeniedLocked=De berichten konden niet worden gefilterd naar de map \u2018%S\u2019 omdat een andere bewerking bezig is.
>+parsingFolderFailed=Het is niet gelukt om de map %S te openen omdat deze in gebruik is door een andere bewerking. Wacht totdat die bewerking klaar is en selecteer de map opnieuw.

Hier geen dan...


>+deletingMsgsFailed=Het is niet gelukt om de berichten in de map %S te verwijderen omdat deze in gebruik is door een andere bewerking. Wacht totdat die bewerking klaar is en probeer het dan opnieuw.
>+compactFolderWriteFailed=De map \u2018%S\u2019 kon niet worden gecomprimeerd omdat het schrijven naar de map is mislukt. Controleer of u genoeg schijfruimte hebt en of u schrijfrechten hebt op het bestandssysteem, en probeer het dan opnieuw.
>+filterFolderWriteFailed=Het bericht kon niet worden gefilterd naar de map \u2018%S\u2019 omdat het schrijven naar de map is mislukt. Controleer of u genoeg schijfruimte hebt en of u schrijfrechten hebt op het bestandssysteem, en probeer het dan opnieuw.
>+copyMsgWriteFailed=De berichten konden niet naar de map \u2018%S\u2019 worden verplaatst of gekopieerd omdat het schrijven naar de map is mislukt. Om schijfruimte te maken, ga naar Bestand, kies eerst Prullenbak legen en dan Mappen comprimeren, en probeer het dan opnieuw.
> cantMoveMsgWOBodyOffline=Tijdens het offline werken kunt u geen berichten verplaatsen of kopi\u00EBren die niet zijn gedownload voor offlinegebruik. Open het menu Bestand in het berichtenvenster, kies Offline en dan Online werken, en probeer het dan opnieuw.

...en hier wel?


> operationFailedFolderBusy=De bewerking is mislukt omdat een andere bewerking de map gebruikt. Wacht totdat die bewerking klaar is en probeer het opnieuw.

...en hier weer niet?

Persoonlijk vind ik het mooier zonder ‘dan’ (en ‘daarna’ heeft mijn voorkeur boven dan... denk ik).


>-USER-AGENT=Gebruikersagent
>+USER-AGENT=Useragent

--> User agent

(Onder het motto: als je het Engels doet, doe het dan goed.)


>-restartLaterMessage=De update die u zojuist hebt gedownload zal de volgende keer dat u %S opstart zijn ge\u00EFnstalleerd.
>+restartLaterMessage=De update die u zojuist hebt gedownload zal de volgende keer dat u %S opstart worden ge\u00EFnstalleerd.

--> heeft gedownload


Met deze verbeteringen een mooie patch die ik graag in de branch zou zien.


~Grauw

p.s. mijn Nederlandse Thunderbird heeft zichzelf vanmiddag automatisch geupdate naar RC1 :). Dat was wel gaaf ;p, tot nu toe was ik vanwege de locale verstoken van automatische updates.
Attached patch css.properties (obsolete) — — Splinter Review 
Deze wijzigingen wil ik graag aanbrengen in de CSS foutmeldingen.

Er zijn in de javascript console tegenwoordig ook een flink aantal non-Javascript-foutmeldingen te zien, en deze zijn vrij zichtbaar voor ontwikkelaars. Met name “Declaratie vrijgegeven” springt in het oog.

Als deze kleine patch nog in de branch kan, dan zou ik dat waarderen.


~Grauw
(In reply to comment #19)
> Is dit niet iets voor bug 314390 dan?
De meeste veranderingen zijn van Ton en via hem had ik begrepen dat Tim Maks hem liever hier had. Misschien uiteindelijk daar.
> Ik snap de wijziging van recent -> recentelijk niet helemaal, beiden zijn goed
> lijkt mij. Maar goed, het is mij om het even.
Ton vond het blijkbaar moooier. Mij maakt het ook niets uit.
> >-fallbackDefaultSearchURL=http://www.google.nl/search?&q=
> >+fallbackDefaultSearchURL=http://nl.start.mozilla.com/firefox
> 
> Dit lijkt mij niet goed. Er wordt een zoekterm achter geconcatenate. Staat ook
> zo in het Engels. Niet wijzigen dus.
Oops, Dit is ook idd niet goed en onbedoeld. De bedoeling was om de entity daarboven (homePageDefault) te wijzigen. Ik was blijkbaar iets te snel met het plakken van die URL.
> >-browser.startup.homepage=http://start.mozilla.org/firefox/
> >+browser.startup.homepage=http://nl.start.mozilla.com/firefox
> 
> Als ik naar http://nl.start.mozilla.com/firefox ga, dan krijg ik een Engelse
> pagina. Dat geldt overigens ook voor de vorige URL. Als ik naar
> http://www.google.nl/firefox ga, dan is het Nederlands.
> 
> Draagt iemand er zorg voor dat nl.start.mozilla.com naar Google.nl wordt
> doorverwezen?
Dit is gebeurd, en bij mij werkt het goed in 1.0.7 nl-NL en 1.5RC1 en-US en nl. Ik weet niet hoe het met 1.0.7 en-US is.

Het moet sowieso veranderd worden voor trademark-reviews. Ze willen eigenlijk niet dat je nog de oude locatie gebruikt.
> >-<!ENTITY findAgainCmd.label "Volgende zoeken">
> >+<!ENTITY findAgainCmd.label "Opnieuw zoeken">
> 
> Is de access key hier ook veranderd naar w?
Ja, deze is veranderd. De constructie was een beetje raar, maar ik heb het getest en in het Bewerken menu wordt nu netjes een w gebruikt.

findnext.accesskey is niet veranderd, maar ik kan niet vinden waar we die gebruikt wordt. Er lijkt daar ook geen label voor te zijn. Ik denk dat we die wel kunnen laten zitten, vanwege die onduidelijkheid. Eventueel ook een w van maken, als die veranderd moet worden.
> >+4015=Het LIST-commando had geen succes. Fout bij verkrijgen van het ID en formaat van een bericht.
> >+4024=Het STAT-commando had geen succes. Fout bij verkrijgen van berichtnummers en -formaten.
> 
> ‘had geen succes’ -> ‘was niet succesvol’
> 
> (we gebruiken elders ook succesvol, en het is mooier)
Ben ik het wel mee eens. Zal ik veranderen.
> >+filterFolderDeniedLocked=De berichten konden niet worden gefilterd naar de map \u2018%S\u2019 omdat een andere bewerking bezig is.
> >+parsingFolderFailed=Het is niet gelukt om de map %S te openen omdat deze in gebruik is door een andere bewerking. Wacht totdat die bewerking klaar is en selecteer de map opnieuw.
> 
> Hier geen dan...
> 
> >+deletingMsgsFailed=Het is niet gelukt om de berichten in de map %S te verwijderen omdat deze in gebruik is door een andere bewerking. Wacht totdat die bewerking klaar is en probeer het dan opnieuw.
> >+compactFolderWriteFailed=De map \u2018%S\u2019 kon niet worden gecomprimeerd omdat het schrijven naar de map is mislukt. Controleer of u genoeg schijfruimte hebt en of u schrijfrechten hebt op het bestandssysteem, en probeer het dan opnieuw.
> >+filterFolderWriteFailed=Het bericht kon niet worden gefilterd naar de map \u2018%S\u2019 omdat het schrijven naar de map is mislukt. Controleer of u genoeg schijfruimte hebt en of u schrijfrechten hebt op het bestandssysteem, en probeer het dan opnieuw.
> >+copyMsgWriteFailed=De berichten konden niet naar de map \u2018%S\u2019 worden verplaatst of gekopieerd omdat het schrijven naar de map is mislukt. Om schijfruimte te maken, ga naar Bestand, kies eerst Prullenbak legen en dan Mappen comprimeren, en probeer het dan opnieuw.
> > cantMoveMsgWOBodyOffline=Tijdens het offline werken kunt u geen berichten verplaatsen of kopi\u00EBren die niet zijn gedownload voor offlinegebruik. Open het menu Bestand in het berichtenvenster, kies Offline en dan Online werken, en probeer het dan opnieuw.
> 
> ...en hier wel?
> 
> > operationFailedFolderBusy=De bewerking is mislukt omdat een andere bewerking de map gebruikt. Wacht totdat die bewerking klaar is en probeer het opnieuw.
> 
> ...en hier weer niet?
> 
> Persoonlijk vind ik het mooier zonder ‘dan’ (en ‘daarna’ heeft mijn voorkeur
> boven dan... denk ik).
Het moet idd consistent zijn. Ik vind het ook nog wat beter klinken zonder dan. Ik zal het zo veranderen, als Ton er problemen mee heeft moet hij maar een seintje geven.
> 
> 
> >-USER-AGENT=Gebruikersagent
> >+USER-AGENT=Useragent
> 
> --> User agent
> 
> (Onder het motto: als je het Engels doet, doe het dan goed.)
Ik had Ton gevraagd dat eruit te halen en was er vanuit gegaan dat dat al gebeurd was. Moet er idd uit.

We willen dan User agent met een spatie ertussen?
> >-restartLaterMessage=De update die u zojuist hebt gedownload zal de volgende keer dat u %S opstart zijn ge\u00EFnstalleerd.
> >+restartLaterMessage=De update die u zojuist hebt gedownload zal de volgende keer dat u %S opstart worden ge\u00EFnstalleerd.
> 
> --> heeft gedownload
We hadden toch afgesproken u hebt te gebruiken? In de help is dat doorgevoerd.

Ik zal nog even ander commentaar afwachten en dan komt er wsl morgenochtend een nieuwe patch waar we dan nog review over kunnen vragen.

> p.s. mijn Nederlandse Thunderbird heeft zichzelf vanmiddag automatisch geupdate
> naar RC1 :). Dat was wel gaaf ;p, tot nu toe was ik vanwege de locale verstoken
> van automatische updates.
Mooi dat dat ook werkt. Firefox auto-update heb ik ook live gezien en dat ging ook vlekkeloos.
(In reply to comment #21)
> > Draagt iemand er zorg voor dat nl.start.mozilla.com naar Google.nl wordt
> > doorverwezen?
> 
> Dit is gebeurd, en bij mij werkt het goed in 1.0.7 nl-NL en 1.5RC1 en-US en nl.
> Ik weet niet hoe het met 1.0.7 en-US is.

Oh, na het wissen van mijn cookies werkt dat inderdaad ook bij mij. Hij doet dan wel twee redirects (één naar google.com, en vervolgens één naar google.nl), ik weet niet of dat gewenst is, maar goed.


> > >-USER-AGENT=Gebruikersagent
> > >+USER-AGENT=Useragent
> > 
> > --> User agent
> > 
> > (Onder het motto: als je het Engels doet, doe het dan goed.)
>
> Ik had Ton gevraagd dat eruit te halen en was er vanuit gegaan dat dat al
> gebeurd was. Moet er idd uit.
> 
> We willen dan User agent met een spatie ertussen?

Yep.


> > >-restartLaterMessage=De update die u zojuist hebt gedownload zal de volgende keer dat u %S opstart zijn ge\u00EFnstalleerd.
> > >+restartLaterMessage=De update die u zojuist hebt gedownload zal de volgende keer dat u %S opstart worden ge\u00EFnstalleerd.
> > 
> > --> heeft gedownload
>
> We hadden toch afgesproken u hebt te gebruiken? In de help is dat doorgevoerd.

Oh... ok. Vind heeft mooier, maar goed, het is niet écht fout.


~Grauw
Nav van de patch van mij en Tonnes en het commentaar van Laurens:
Ik zie in messenger.properties ook 'probeer het later opnieuw' (2x) en 'Probeer het later nog eens' voorkomen. Ik denk dat we hier ook maar 'probeer het opnieuw' moeten gaan gebruiken. Mee eens?
Comment on attachment 202140 [details] [diff] [review]
A lot of improvements by Ton and myself

please make a new patch with the commends of grauw. If it is possible split the patches in two: 1 need to go into the branch and one would be nice to go into the branch
I splitted the patch in two parts. This part is the largest one and contains fixed which would be nice for branch. The other patch will I post in the RC-bug and contains the region.properties changes, the Software-update spelling correction, a changed menu item in the help and herhalen -> opnieuw uitvoeren, because of consistency. Those are the most important changes.
Attachment #202140 - Attachment is obsolete: true
Comment on attachment 202158 [details] [diff] [review]
css.properties

Would be nice to get this into the branch, but nl is already frozen.
Attachment #202158 - Flags: approval-l10n?
Comment on attachment 202227 [details] [diff] [review]
Improved patch with comments from Grauw.

We would also like approval for this patch.
Attachment #202227 - Flags: approval-l10n?
Comment on attachment 202158 [details] [diff] [review]
css.properties

Toegepast op branch en trunk. Approval was volgens Pike niet nodig, hoorde ik op IRC.
Attachment #202158 - Attachment is obsolete: true
Attachment #202158 - Flags: approval-l10n?
Comment on attachment 202227 [details] [diff] [review]
Improved patch with comments from Grauw.

Toegepast op branch en trunk
Attachment #202227 - Attachment is obsolete: true
Attachment #202227 - Flags: approval-l10n?
(In reply to comment #21)
> (In reply to comment #19)
> > 
> > Ik snap de wijziging van recent -> recentelijk niet helemaal, beiden zijn goed
> > lijkt mij. Maar goed, het is mij om het even.
> Ton vond het blijkbaar moooier. Mij maakt het ook niets uit.

Als het goed is is recent een b.n. en recentelijk een bijwoord.

> > ‘had geen succes’ -> ‘was niet succesvol’
> > 
> > (we gebruiken elders ook succesvol, en het is mooier)
> Ben ik het wel mee eens. Zal ik veranderen.

Eens, maar er zijn in dit bestand nog meer string die dan ook naar die vorm moeten worden gewijzigd.

> > Hier geen dan...
> > 
> > ...en hier wel?
> > 
> > ...en hier weer niet?
> > 
> > Persoonlijk vind ik het mooier zonder ‘dan’ (en ‘daarna’ heeft mijn voorkeur
> > boven dan... denk ik).
> Het moet idd consistent zijn. Ik vind het ook nog wat beter klinken zonder dan.
> Ik zal het zo veranderen, als Ton er problemen mee heeft moet hij maar een
> seintje geven.

Geen probleem. Ik ben dacht ik wel uitgegaan van de originele tekst, met daarbij de gedachte dat dan/daarna soms overbodig kan zijn als er een tijdsbepaling aan vooraf gaat, en daarom 'daarna' wat beter staat in een nieuwe zin en niet na 'en', en 'then' in principe 'dan' betekent . Maar idd niet consistent.

> > >-USER-AGENT=Gebruikersagent
> > >+USER-AGENT=Useragent
> > 
> > --> User agent
> > 
> > (Onder het motto: als je het Engels doet, doe het dan goed.)
> Ik had Ton gevraagd dat eruit te halen en was er vanuit gegaan dat dat al
> gebeurd was. Moet er idd uit.

Hoewel ik niet zo'n probleem had met gebruikersagent vond ik user agent ook wel in orde, maar het leek me logischer dit aan elkaar te zetten, zoals gebruikelijk bij Engelse termen die in het Nederlands worden overgenomen, toch? Dusseh.. dat motto... ;)

> > --> heeft gedownload
> We hadden toch afgesproken u hebt te gebruiken? In de help is dat doorgevoerd.

Idd, overal is 'u heeft' 'u hebt' geworden, en verwant.

Dan uit Laurens' patch, att 202158: 
PEUnknownNamespacePrefix=Onbekende namespace-prefix \u2018%1$S\u2019.
Onbekend -> onbekende

Dit wilde ik ook meenemen, maar zag dat het 'het prefix' schijnt te zijn, ondanks wat ik zelf dacht. Hoe denk jij daarover? Als dit 'de' blijft, dan even verder kijken want er zijn geloof ik nog een paar van dit soort gevallen.

Decalaration dropped: een goeie, want na overleg in #L10n was ooit de betekenis duidelijk, maar genegeerd is daarin idd beter. En uiteraard parsen ook OK.
Dit zijn dan echt de laatste verbeteringen, weer ontdekt door Ton en mijzelf. Het zijn simpele wijzigingen, waar volgensmij niemand problemen mee heeft. Aangezien we morgenochtend (NL tijd) echt bevriezen pas ik dit gelijk toe.
Comment on attachment 202310 [details] [diff] [review]
Nog wat laatste verbeteringen, ontdekt na toepassen laatste patch

Toegepast op branch en trunk
Attachment #202310 - Attachment is obsolete: true
Kan iemand mij nog eens laten weten hoe het nu zat met het al dan niet verwijderen van ‘Bezig te/met’, ‘Aan het’ en dergelijke?  Ik heb er nog een heleboel die ik graag weg zou zien, maar ik kan me niet herinneren of daar nu bezwaren tegen waren.

Verder ben ik er nog steeds voor om linker koptekst door linkerkoptekst dan wel linkse koptekst te vervangen.  Wat dat betreft ben ik onlangs het volgende tegengekomen in Taalpost 462, zie www.taalpost.nl:
2. Taaltip: 'linker' en 'rechter'
Worden combinaties met 'linker' en 'rechter' altijd aaneengeschreven of is los ook (soms) goed?
Voor het al dan niet aaneenschrijven van combinaties met 'linker' en 'rechter' bestaat geen vaste regel. Wel
neemt het Groene Boekje veel woorden op waarin 'linker' en 'rechter' deel uitmaken van een samenstelling:
'linkerarm', 'linkermiddenvelder', 'rechterhand', 'rechteroever'. Daarbij valt op dat in al die woorden 'rechts' of
'links' een vaste eigenschap is: hoe je je ook wendt of keert, je linkerbeen blijft altijd je linkerbeen en je
rechteroog altijd je rechteroog. En ook in onder meer sporttermen en infrastructurele begrippen is links of
rechts vaak zo'n vaste eigenschap: een linkerspits is ook een linkerspits als de doelman hem rechts ziet, en
de snelweg heeft twee rechterrijstroken.
Aaneenschrijven is in toevallige combinaties ook mogelijk - er liggen twee boeken naast elkaar, je noemt het
ene het rechterboek en het andere het linkerboek - maar los schrijven is eveneens te verdedigen. 'Rechter'
en 'linker' zijn van oorsprong namelijk bijvoeglijke naamwoorden. Daardoor kun je nog steeds zeggen: 'Welk
boek wil je: het rechter of het linker?' Delen van 'echte' samenstellingen kun je niet zo gebruiken: 'Welke fiets
wil je: de bak- of de race-?' is geen normale Nederlandse zin.
Door onderscheid aan te brengen tussen de vaste en de toevallige eigenschap 'links' of 'rechts' kun je
verschil maken tussen 'rechter oever' (op dat moment bekeken) en 'rechteroever' (stroomafwaarts gezien),
en tussen 'rechter schoen' (bij een rijtje schoenen in de winkel bijvoorbeeld) en 'rechterschoen' (voor de
rechtervoet).

Ik zie ze hier eerder aaneen omdat het links zijn hier onafhankelijk is van de kijkrichting, maar vastligt door de tekstrichting (zoals in het linkerspitsvoorbeeld).
Anderzijds moet ik toegeven dat op http://www.onzetaal.nl/advies/linker.html eigenlijk het tegendeel geadviseerd wordt.
Op zich heb ik zelf geen fundamenteel bezwaar tegen linkerkoptekst, maar aangezien http://www.onzetaal.nl/advies/linker.html inderdaad een redelijke case maakt om het los van elkaar schrijven, en ik bovendien geen voorstander ben van dingen wijzigen als de wijziging niet duidelijk de situatie verbeterd...

Nuja. Wat mij betreft dus, laat het maar zo. En als het toch gewijzigd moet worden, dan zeker niet linkse koptekst, maar gewoon aan elkaar.


~Grauw
(In reply to comment #33)
> Kan iemand mij nog eens laten weten hoe het nu zat met het al dan niet
> verwijderen van ‘Bezig te/met’, ‘Aan het’ en dergelijke?  Ik heb er nog een
> heleboel die ik graag weg zou zien, maar ik kan me niet herinneren of daar nu
> bezwaren tegen waren.

Of het nu mooi wordt gevonden of niet, 'bezig met' en/of 'aan het' zijn m.i. te belangrijk om zomaar overal weg te halen, omdat het belangrijke statusinfo betreft die meestal en feitelijk onmisbaar is. Hier en daar zou het er dus eigenlijk nog in moeten.. Wel vind ik dat e.e.a. consistent mag worden gemaakt, als de tekst dit toelaat tenminste. Misschien klinkt het wat vreemd, maar ik ga het eigenlijk een beetje als een belediging van de Nederlandse taal beschouwen als er wordt geprobeerd deze vorm te elimineren. Is het nu echt zo ernstig dat hier óók al een infinitief moet komen? Computeracties zijn het al of moeten het hier en daar misschien nog worden (bv. in editor), sommige gebruikeracties zijn meen ik vervangen, de 3e persoon enkelvoud zoals in tooltips is ook al stilletjes aan het verdwijnen, al dan niet per ongeluk.. :( Dan nu ook nog 'bezig met'/'aan het' of een vorm als 'installerend' er overal uit? Liever niet dus.

> Verder ben ik er nog steeds voor om linker koptekst door linkerkoptekst dan wel
> linkse koptekst te vervangen.  Wat dat betreft ben ik onlangs het volgende
> tegengekomen in Taalpost 462, zie www.taalpost.nl:

Toen we het hier eerder over hadden werd los schrijven in orde bevonden en 'linkse' was uitgesloten. Ondanks de interessante toevoeging hierboven ben ik van mening dat we ons toch beter aan het advies op Onzetaal kunnen houden, want hoewel er wel iets valt te zeggen over het vaststaan van links of rechts bij de kop- en voetteksten is los schrijven op meerdere manieren te verdedigen. Zo lijkt een grammaticale regel zoals die op Onzetaal eenvoudiger in het gebruik en de voorkeur te krijgen boven een betekenisafhankelijke als in het voorbeeld van 'rechterschoen', wat doet denken aan de oude 'kippe(n)vleesregel'. Ook zul je nog niet gauw 'linkerkoptekst' tegenkomen in een woordenboek, al zegt dat natuurlijk niet alles. Verder is er kans op het lezen als 'linkerkop-tekst' (linkervoet-tekst?) en ook niet onbelangrijk: de leesbaarheid van vreemde termen in het algemeen. Let wel: ik ben geen voorstander o.i.d. van het begrip woordgroep en daardoor los schrijven zoals je eerder zei, integendeel. Wel denk ik dat men niet per sé dingen aan elkaar moet schrijven zodra de kans er is, al dan niet vanwege een minder grote voorkeur voor koppeltekens, of doordat de schrijver mogelijk minder moeite heeft met het lezen van langere niet-veelvoorkomende woorden dan men zou kunnen verwachten van de gemiddelde lezer/gebruiker, zelfs bij een eenvoudig lijkende toevoeging als 'linker'. Dit houdt dus ook in dat men zo af en toe een koppelteken kan gebruiken of laten staan t.b.v. leesbaarheid, en zo ook een spatie in een geval als dit, zolang dit tenminste 'legaal' is. Wat een koptekst is weet de gemiddelde gebruiker wel (hij wijzigt immers de kop- en voetteksten), maar een woord als linkerkoptekst leest toch net iets moeilijker dan linkerweghelft, linker koptekst of zelfs linkermarge en is dus zeker voor een tooltip niet aan te raden, naar mijn mening.

Nu we het toch over spaties en koppeltekens hebben: ik maak me eerder zorgen over de ook eerder besproken maar nog niet afgeronde gevallen van '8-bits'. Zoals gezegd zou het naar mijn idee hooguit '8-bitteken' kunnen zijn, maar alleen als dit een ingeburgerde term was. Dat is het niet en waarschijnlijk daardoor nergens als zodanig terug te vinden, dus '8-bits tekens' lijkt me beter op zijn plaats, ook vanwege consistentie. Dit is ook begrijpelijker voor de gebruiker; meteen is duidelijk dat het over bepaalde tekens gaat en niet, om voor de verandering maar eens met het Vlaams te schermen, over een [:bíttukun] (een beetje), wat het nóg verwarrender maakt. Overigens zou 'teken' hier 'karakter' kunnen of misschien wel moeten zijn (of omgekeerd in de overige gevallen), wat het laatste bezwaar weliswaar wegneemt ('8-bitkarakter') maar ook dat is denk ik niet aan te raden en nog steeds inconsistent. Zo zit er ook nog 2 keer '8-bits-ascii-karakters' in de tekst, wat zoals gezegd naar mijn idee géén geval van '24-uurseconomie' is. Dat woord is een zuivere samenstelling waarin het deel '24-uur' (plus tussen-s) net als in 1-aprilgrap een met meerdere woorden te omschrijven type-eigenschap is, en het dus niet gaat om zoiets als een 24 uur lange economie. Een geval van een 8-bits (breed) getal is net als dat van een 4-duims (dikke) pvc-pijp iets heel anders, en of '8-bits' nu een bijvoeglijk naamwoord, bijwoord of bijwoordelijke bepaling of iets anders is, daar wil ik even vanaf zijn. Ik hoop dat dit nu duidelijk is en zou beide termen graag teruggewijzigd zien naar '8-bits tekens' (of '8-bits karakters') resp. '8-bits ascii-karakters' (of '8-bits ascii-tekens') zodat het ook weer matcht met soortgelijke termen in pref-ssl.dtd.
(In reply to comment #35)
> (In reply to comment #33)
> > Kan iemand mij nog eens laten weten hoe het nu zat met het al dan niet
> > verwijderen van �Bezig te/met�, �Aan het� en dergelijke?  Ik heb er nog een
> > heleboel die ik graag weg zou zien, maar ik kan me niet herinneren of daar nu
> > bezwaren tegen waren.
> 
> Of het nu mooi wordt gevonden of niet, 'bezig met' en/of 'aan het' zijn m.i. te
> belangrijk om zomaar overal weg te halen, omdat het belangrijke statusinfo
> betreft die meestal en feitelijk onmisbaar is. Hier en daar zou het er dus
> eigenlijk nog in moeten.. Wel vind ik dat e.e.a. consistent mag worden gemaakt,
> als de tekst dit toelaat tenminste. Misschien klinkt het wat vreemd, maar ik ga
> het eigenlijk een beetje als een belediging van de Nederlandse taal beschouwen
> als er wordt geprobeerd deze vorm te elimineren. Is het nu echt zo ernstig dat
> hier ��k al een infinitief moet komen? Computeracties zijn het al of moeten het
> hier en daar misschien nog worden (bv. in editor), sommige gebruikeracties zijn
> meen ik vervangen, de 3e persoon enkelvoud zoals in tooltips is ook al
> stilletjes aan het verdwijnen, al dan niet per ongeluk.. :( Dan nu ook nog
> 'bezig met'/'aan het' of een vorm als 'installerend' er overal uit? Liever niet
> dus.

Ik heb er geen probleem mee om de stap van Installeren... naar Bezig met installeren... in mijn hoofd te maken, al helemaal niet al het een schermpje is dat langere tijd daar is, maar inderdaad kan het ook wel blijven.  Ik ben wel voor het beknopte van een infinitief.

> > Verder ben ik er nog steeds voor om linker koptekst door linkerkoptekst dan 

Ok, overtuigende argumenten.  Het is toch soms lastig om met anderen samen te werken, pft.
 
> Nu we het toch over spaties en koppeltekens hebben: ik maak me eerder zorgen
> over de ook eerder besproken maar nog niet afgeronde gevallen van '8-bits'.

> zou beide termen graag teruggewijzigd zien naar '8-bits tekens' (of '8-bits
> karakters') resp. '8-bits ascii-karakters' (of '8-bits ascii-tekens') zodat het
> ook weer matcht met soortgelijke termen in pref-ssl.dtd.

Daar kan ik nog aan toevoegen dat in de (binnenkort) vernieuwde spelling duidelijkere regels over zulke gevallen zijn, die ik weliswaar nog niet tot in de details bestudeerd heb, maar die in ieder geval impliceren dat het nu 24 uurseconomie en 1 aprilgrap is (alleen maar minder duidelijk als je het mij vraagt).  Wat m.i. tot 8 bits tekens dan wel 8 bittekens dan wel 8 bitkarakters leidt.  In dat geval is het eerste toch wel zeer dubbelzinnig.  Ik stel voor hier nog maar eens de taaladviesdienst ter hulp te roepen.
(In reply to comment #35)
> (In reply to comment #33)
> > Verder ben ik er nog steeds voor om linker koptekst door linkerkoptekst dan wel
...
> termen in het algemeen. Let wel: ik ben geen voorstander o.i.d. van het begrip
> woordgroep en daardoor los schrijven zoals je eerder zei, integendeel. Wel 
Vlak na mijn vorige opmerking begon ik hierover wat te lezen op http://www.standaard.be/Artikel/Detail.aspx?artikelId=GL2J0KHM, en ik stel voor dat je dat ook eens leest, zodat de terminologie wat duidelijker wordt: bijna steeds als jij het over woordgroepen hebt, bedoel je samenkoppeling, of iets wat eigenlijk niet bestaat. (Tenzij ik het hier weer te strikt interpreteer.)
Overigens staat daar nog maar eens een argument om linker- en rechter- (bijna) altijd aan het volgende woord vast te schrijven...

Ook zeer belangrijk: "NIEUW! Deze lijst is beperkt. Na bijvoorbeeld pseudo-, semi-, quasi- en privé- schrijven we vanaf de Spelling 2005 geen koppelteken meer." Vanaf nu dus privégegevens (eindelijk, als je het mij vraagt ;-))

8-bits tekens lijkt ook door Emacs gebruikt te worden, is sowieso het enige wat op het internet voorkomt, en de vergelijking met 4-duims houdt steek, dus ok.
Attached patch Bezig met en andere kleinigheden (obsolete) — — Splinter Review 
Na overleg op irc: bezig te -> bezig met, verder nog een online-, een vergeten vertaling, ...
(In reply to comment #36)
> 
> > Nu we het toch over spaties en koppeltekens hebben: ik maak me eerder zorgen
> > over de ook eerder besproken maar nog niet afgeronde gevallen van '8-bits'.
> 
> Daar kan ik nog aan toevoegen dat in de (binnenkort) vernieuwde spelling
> duidelijkere regels over zulke gevallen zijn, die ik weliswaar nog niet tot in
> de details bestudeerd heb, maar die in ieder geval impliceren dat het nu 24
> uurseconomie en 1 aprilgrap is (alleen maar minder duidelijk als je het mij
> vraagt).  Wat m.i. tot 8 bits tekens dan wel 8 bittekens dan wel 8 bitkarakters
> leidt.  In dat geval is het eerste toch wel zeer dubbelzinnig.  Ik stel voor
> hier nog maar eens de taaladviesdienst ter hulp te roepen.

Hmja, is mogelijk. Over die nieuwe regels heb ik e.e.a. gelezen maar begreep daaruit dat deze verandering alleen geldt bij bekende woordgroepen zoals '1 april' en '24 uur' e.d. (zie ook http://www.onzetaal.nl/advies/aprilgrap.html). De truuk is kennelijk dat zo'n bekende woordgroep die zelfstandig dus los wordt geschreven, zonder streepje geen verwarring kan opleveren in een samenstelling, en alleen dan. Wordt '8-bits' los geschreven dan is dat een b.n. of bijwoord en in '8-bittekens' is het eerste deel geen bekende woordgroep, dus de regel volgens mij niet van toepassing. Ook blijft zoals gezegd de vraag of dergelijke tekens bestaan en of het daarom geoorloofd is om het bijvoeglijke/bijwoordelijke deel eraan vast te schrijven. Technisch gezien blijft een karakter immers hetzelfde karakter, en is alleen zijn voor de opslag gebruikte bitbreedte 8- of 16-bits (CMIIW).

(In reply to comment #37)
> >
> > termen in het algemeen. Let wel: ik ben geen voorstander o.i.d. van het begrip
> > woordgroep en daardoor los schrijven zoals je eerder zei, integendeel. Wel 
> >
> Vlak na mijn vorige opmerking begon ik hierover wat te lezen op
> http://www.standaard.be/Artikel/Detail.aspx?artikelId=GL2J0KHM, en ik stel voor
> dat je dat ook eens leest, zodat de terminologie wat duidelijker wordt: bijna
> steeds als jij het over woordgroepen hebt, bedoel je samenkoppeling, of iets
> wat eigenlijk niet bestaat. (Tenzij ik het hier weer te strikt interpreteer.)

Het kan inderdaad zo zijn dat ik wat gauw de term woordgroep hanteer zodra iets geen samenstelling is, al kan ik me niet zo gauw herinneren waar dat ten onrechte was. Samenkoppelingen zijn zelfs nog niet voorgekomen, of je moet 'Firefox-homepage' daaronder plaatsen? Iets wat me nog niet lekker zit en waarver de nieuwe spelling ook niet duidelijk is..

> Overigens staat daar nog maar eens een argument om linker- en rechter- (bijna)
> altijd aan het volgende woord vast te schrijven...

Hetzelfde argument als eerder eigenlijk, wat blijkbaar in strijd is met dat op Onzetaal, al geeft men daar wel aan dat bepaalde adviezen misschien nog niet zijn aangepast aan het GB 2005, dus ik ben nu wel erg benieuwd wat daarin actueel is. Nog een tegenargument: los schrijven staat beter t.o.v. 'Middelste koptekst'.

> Ook zeer belangrijk: "NIEUW! Deze lijst is beperkt. Na bijvoorbeeld pseudo-,
> semi-, quasi- en privé- schrijven we vanaf de Spelling 2005 geen koppelteken
> meer." Vanaf nu dus privégegevens (eindelijk, als je het mij vraagt ;-))

Is idd logischer. :)

> 8-bits tekens lijkt ook door Emacs gebruikt te worden, is sowieso het enige wat
> op het internet voorkomt, en de vergelijking met 4-duims houdt steek, dus ok.

Kijk ook nog even onder 'Samenstelling met een cijfer erin' op de bovengenoemde pagina, en met name '14-daags' en '1 april'.



(In reply to comment #38)
> Created an attachment (id=203721) [edit]
> Bezig met en andere kleinigheden
> 
> Na overleg op irc: bezig te -> bezig met, verder nog een online-, een vergeten
> vertaling, ...

> gratis online encyclopedie -> gratis online-encyclopedie
Niet echt fout als online een b.n. is, maar dit kan ook en is misschien wat logischer.

> # LOCALIZATION NOTES(attachmentDeletePrefix): Do not translate until foreign
> language attachment names are fixed
> -attachmentDeletePrefix=Deleted: %S
> +attachmentDeletePrefix=Verwijderd: %S
Is niet vergeten maar mag volgens mij nog niet vertaald worden. (bug 303443)

> +ReplaceSharedFile=Bezig met vervangen gedeeld bestand: %s
> +SkipSharedFile=Bezig met overslaan gedeeld bestand: %s
Plus 'van', net als overige?

> +DeleteComponent=Bezig met verwijderen van  component: %s
Spatie..

Comment on attachment 203721 [details] [diff] [review]
Bezig met en andere kleinigheden

ben deze aan het herwerken, er komt nog veel meer en trok toch op niks...
Attachment #203721 - Attachment is obsolete: true
Attached patch karakters -> tekens (obsolete) — — Splinter Review 
Aangezien eerder duidelijk werd dat het laatste de voorkeur had, inclusief de drie 8-bitsgevallen.
(In reply to comment #42)
> Created an attachment (id=204003) [edit]
> karakters -> tekens
> 
> Aangezien eerder duidelijk werd dat het laatste de voorkeur had, inclusief de
> drie 8-bitsgevallen.

+NoSeparatorCharacter=Voer een enkel teken in om te gebruiken voor het delen in kolommen
Zouden we hier niet VERdelen in kolommen van maken?

En weer eens te veel streepjes naar mijn zin, maar ok hoor :-p
Attached patch Bezig met, tweede keer (obsolete) — — Splinter Review 
Deze keer overal op ‘te’ en ‘aan het’ gecontroleerd, en er overal ‘bezig met’ van gemaakt.  Opmerkingen over de stijl welkom (vaak werkwoorden in zelfstandige naamwoorden veranderd).

Verder nog enkele kleinere dingetjes.
Verder wou ik eens informeren vanaf wanneer we de nieuwe spelling gaan gebruiken.  Deze is weliswaar pas van kracht vanaf augustus, maar het kan geen kwaad om dit al te beginnen gebruiken in nieuwe vertalingen en hier en daar een aanpassing te doen (ik denk aan privé-x, nu zonder streepje).
(In reply to comment #43)
> 
> +NoSeparatorCharacter=Voer een enkel teken in om te gebruiken voor het delen in
> kolommen
> Zouden we hier niet VERdelen in kolommen van maken?

Prima. Het 'enkel' kan w.m.b. ook wel weg, maar ach..

> En weer eens te veel streepjes naar mijn zin, maar ok hoor :-p

:) Ik vind een streepje in 'unicode-karakters' ook al beter staan, maar bij tekens vind ik het haast onmisbaar ([unico-détekens]?).

(In reply to comment #45)
> Verder wou ik eens informeren vanaf wanneer we de nieuwe spelling gaan
> gebruiken.  Deze is weliswaar pas van kracht vanaf augustus, maar het kan geen
> kwaad om dit al te beginnen gebruiken in nieuwe vertalingen en hier en daar een
> aanpassing te doen (ik denk aan privé-x, nu zonder streepje).

Lijkt me voor de trunk eigenlijk wel logisch. Ik vermoed dat 2.0 pas rond die tijd verschijnt en zo niet, dan scheelt dit niet veel en kan het zeker geen kwaad.
Attached file Commentaar op att. 204034 (obsolete) — 
(In reply to comment #44)
> Created an attachment (id=204034) [edit]
> Bezig met, tweede keer

Vanwege de lengte van het commentaar maar als een tekstbestand aan de bug gehangen.

Nog een algemene opmerking: is het handig om eerst de huidige verschillen met de 1.8-branch op te lossen voordat nieuwe patches worden toegepast?
(In reply to comment #47)
Algemeen antwoord: 
- ik vond het mooier znw´s te gebruiken en heb dat gedaan waar het kon, maar dat hoeft idd niet
- ik heb geprobeerd de stijl van voordien aan te houden; telegramstijl -> het weglaten, anders niet (vergelijk met de vorige versie, ik heb niet naar het Engels gekeken)
- de vreemde tekens zijn erin geslopen door Eclipse, ik moet daar eens een hoop bugs gaan rapporteren over de CVS-component.

Specifiek: 
- ogenblik: idd
- waarom wil je `uw´?  Als de updates al eerder vermeld zijn, kan je toch ook gewoon `de´ gebruiken, geen ambiguïteit.
- README: foutje, veronderstel ik

-#define MSG_USAGE ... Forceert dat GRE ... Forceert dat GRE ... Forceer installatie ...  Forceert het downloaden ...
 Dit\n misleidt de logica van GRE ... zal overschrijven
+#define MSG_USAGE ... Dwingt af dat GRE .. Dwingt af dat GRE .. Dwingt installatie ... Dwingt het downloaden ...
 Dit\n gaat voorbij aan .. die GRE gebruikt ... zal onderdrukken

- Ik vind forceren echt niet op zijn plaats hier.  Het heeft gewoon een andere betekenis.  Ik gebruik het woord ook hoor.  Dwingen kan, maar dan moet het iets als `Dwingt GRE te...´ worden.
Over infinitief vs. persoonsvorm is voor deze string al ettelijke malen gediscussieerd, ik blijf eraf.
- Ik zie snap niet wat je zo formeel vindt in `gaat voorbij aan´, maar omzeilt vind ik ook mooier.
- Heb je wel in het woordenboek gekeken bij override?  Overschrijven is in ieder geval fout, er wordt niks veranderd aan dat bestand.  Onderdrukken staat als één van de synoniemen in de grote Van Dale E/N, en lijkt me hier het meest op zijn plaats.  Snap niet hoe je eerst kan klagen over te formeel en dan met een woord als prevaleren afkomen...

Index: toolkit/installer/windows/install.it
Geen UTF gebruiken in dit bestand. Niet zo lang geleden heeft dit nog problemen gegeven. (bug 305315, c 207)
Ik zie het probleem, maar wat is de oplossing?

-BookmarksLivemarkLoading=Bezig live bladwijzers te laden...
+BookmarksLivemarkLoading=Live bladwijzer laadt...
Zo?  Of ... IS bezig met laden.
(In reply to comment #48)
> (In reply to comment #47)
> - ik heb geprobeerd de stijl van voordien aan te houden; telegramstijl -> het
> weglaten, anders niet (vergelijk met de vorige versie, ik heb niet naar het
> Engels gekeken)

Daar zit wat in, maar het is denk ik wel verstandig om naast de globaal gebruikte stijl ook naar het Engels te blijven kijken vanwege het gevaar dat de vertaling steeds meer gaat afwijken. Ook fouten en vergeten zaken komen zo eerder aan het licht.

> - waarom wil je `uw´?  Als de updates al eerder vermeld zijn, kan je toch ook
> gewoon `de´ gebruiken, geen ambiguïteit.

Tja, in de eerste plaats natuurlijk vanwege de Engels versies van updater.ini, maar ook omdat 'uw' een goede weergave is van 'de updates die voor u van toepassing zijn', i.p.v. 'wat' updates. Net zoiets als 'updates voor uw extensies' eigenlijk. Van ambiguïteit (mooi woord trouwens) is volgens mij geen sprake.
 
> -#define MSG_USAGE ... Forceert dat GRE ... Forceert dat GRE ... Forceer
> installatie ...  Forceert het downloaden ...
>  Dit\n misleidt de logica van GRE ... zal overschrijven
> +#define MSG_USAGE ... Dwingt af dat GRE .. Dwingt af dat GRE .. Dwingt
> installatie ... Dwingt het downloaden ...
>  Dit\n gaat voorbij aan .. die GRE gebruikt ... zal onderdrukken
> 
> - Ik vind forceren echt niet op zijn plaats hier.  Het heeft gewoon een andere
> betekenis.  Ik gebruik het woord ook hoor.  Dwingen kan, maar dan moet het iets
> als `Dwingt GRE te...´ worden.

Dat laatste bedoelde ik. Hoe dan ook, forceren is in de betekenis van 'dwingen' niet echt fout (in NL). Verder ga ik me afvragen of het er in de instellingen voor tabbladen ook uit zou moeten, als het hier gebeurt.

> Over infinitief vs. persoonsvorm is voor deze string al ettelijke malen
> gediscussieerd, ik blijf eraf.

Niet te snel; deze voorkomens zijn blijkbaar nog verkeerd vertaald (forces/forces/force/force) en het is juist vanwege die discussie dat deze 2 nieuwe gevallen opvielen.

> - Ik zie snap niet wat je zo formeel vindt in `gaat voorbij aan´, maar omzeilt
> vind ik ook mooier.

'Gaat voorbij aan' lijkt me (in NL) niet echt iets voor computerprogramma's, meer voor personen die ergens geen rekening mee houden. Omzeilen ligt dan idd meer voor de hand.

> - Heb je wel in het woordenboek gekeken bij override?  Overschrijven is in
> ieder geval fout, er wordt niks veranderd aan dat bestand.  Onderdrukken staat
> als één van de synoniemen in de grote Van Dale E/N, en lijkt me hier het meest
> op zijn plaats.  Snap niet hoe je eerst kan klagen over te formeel en dan met
> een woord als prevaleren afkomen...

Grappig om te zien dat je soms hetzelfde zegt als ik en mij dan ergens op wilt wijzen. :) Ja, ik kijk bij twijfel altijd in het woordenboek en deed dat hier ook, en indien nodig zoek ik naar eerdere probleemgevallen. Conclusie: onderdrukken mag een synoniem zijn (van wat overigens, en hoe haal je dat uit de Van Dale?), maar de betekenis klopt hier totaal niet. Onderdrukken is in het Nederlands in zijn eerste en wellicht alle betekenissen iets anders dan override, waarmee men v.z.i.w. 'voorrang hebben op iets anders' bedoelt, iets waar men zeker niet aan denkt bij onderdrukken (m.a.w. onderdrukken=suppress). 'Prevaleren' mag dan wat formeel lijken maar is hier denk ik wel het meest geaccepteerde woord voor dat doel, en anders toch maar 'heeft voorrang op'.

> Index: toolkit/installer/windows/install.it
> Geen UTF gebruiken in dit bestand. Niet zo lang geleden heeft dit nog problemen
> gegeven. (bug 305315, c 207)
> Ik zie het probleem, maar wat is de oplossing?

Vermoedelijk gebeurt dit automatisch, dus zul je in ascii- of Windows-codering o.i.d. moeten opslaan. Notepad is ook een goeie. :)

> -BookmarksLivemarkLoading=Bezig live bladwijzers te laden...
> +BookmarksLivemarkLoading=Live bladwijzer laadt...
> Zo?  Of ... IS bezig met laden.

Ik zou kiezen voor 'Live bladwijzer bezig met laden'.
(In reply to comment #49)
> (In reply to comment #48)
> > (In reply to comment #47)
> > - ik heb geprobeerd de stijl van voordien aan te houden; telegramstijl -> het
> > weglaten, anders niet (vergelijk met de vorige versie, ik heb niet naar het
> > Engels gekeken)
> 
> Daar zit wat in, maar het is denk ik wel verstandig om naast de globaal
> gebruikte stijl ook naar het Engels te blijven kijken vanwege het gevaar dat de
> vertaling steeds meer gaat afwijken. Ook fouten en vergeten zaken komen zo
> eerder aan het licht.

Daar heb ik hou voor ;-)  Nee, tuurlijk, doe ik ook regelmatig wel hoor.

> > - waarom wil je `uw´?  Als de updates al eerder vermeld zijn, kan je toch ook
> > gewoon `de´ gebruiken, geen ambiguïteit.
> 
> Tja, in de eerste plaats natuurlijk vanwege de Engels versies van updater.ini,
> maar ook omdat 'uw' een goede weergave is van 'de updates die voor u van
> toepassing zijn', i.p.v. 'wat' updates. Net zoiets als 'updates voor uw
> extensies' eigenlijk. Van ambiguïteit (mooi woord trouwens) is volgens mij geen
> sprake.

Ik bedoel ook geen amgiguïteit bij gebruik van `de´.  Ik heb de neiging zo veel mogelijk persoonlijk vnw'en weg te laten, zal wel met mijn programmeerwerk te maken hebben (stel dat je ze ooit moet veranderen -> minder werk)

> > -#define MSG_USAGE ... Forceert dat GRE ... Forceert dat GRE ... Forceer
> > - Ik vind forceren echt niet op zijn plaats hier.  Het heeft gewoon een andere
> Dat laatste bedoelde ik. Hoe dan ook, forceren is in de betekenis van 'dwingen'
> niet echt fout (in NL). 

Ik gebruik forceren in zinnen als `een doorbraak forceren´, `een slot forceren´ (=kapot breken) maar niet in de zin van `iemand/iets forceren iets te doen´.

> > - Heb je wel in het woordenboek gekeken bij override?  Overschrijven is in
> onderdrukken mag een synoniem zijn (van wat overigens, en hoe haal je dat uit
> de Van Dale?), 

Van de hoofdbetekenis die gegeven werd, ik bedoel natuurlijk de grote Van Dale E/N, niet de `dikke´ Van Dale.

> maar de betekenis klopt hier totaal niet. Onderdrukken is in het
> Nederlands in zijn eerste en wellicht alle betekenissen iets anders dan
> override, waarmee men v.z.i.w. 'voorrang hebben op iets anders' bedoelt, iets
> waar men zeker niet aan denkt bij onderdrukken (m.a.w. onderdrukken=suppress).

Ok, onderdrukken is hier wel tweeduidig, maar je kan toch ook een neiging onderdrukken, dan lijkt me de stap naar instellingen overdrukken snel gemaakt.

> 'Prevaleren' mag dan wat formeel lijken maar is hier denk ik wel het meest
> geaccepteerde woord voor dat doel, en anders toch maar 'heeft voorrang op'.

Ik vind het vooral een afschuwelijk woord.

> > Index: toolkit/installer/windows/install.it

Kan iemand van de computerexperten me hier opklaring geven?  (Evt. specifiek voor Eclipse?)
(In reply to comment #50)
> > > Index: toolkit/installer/windows/install.it
> 
> Kan iemand van de computerexperten me hier opklaring geven?  (Evt. specifiek
> voor Eclipse?)

Ik wacht vooral nog op een antwoord hierop voordat ik een nieuwe versie van de patch maak... 


Ik weet niet of dit het antwoord is wat je zoekt, maar in Eclipse kan je rechts-klikken op die file en in de properties de encoding van die file expliciet op Latin-1 zetten. Dan zal hij daarnaar geen Latin-1 schrijven. Ik weet niet of je dit ook globaal ‘voor alle bestanden met extensie .it’ in kunt stellen. Het zal vast wel, ergens, maar ik denk dat het sowieso niet vaak voorkomt.


~Grauw
> Dan zal hij daarnaar geen Latin-1 schrijven.

Ik bedoel, dan zal hij daarna als Latin-1 wegschrijven en inlezen, en niet meer als UTF-8.


~Grauw
Attached patch bezig met, tris (obsolete) — — Splinter Review 
- zelfstandige naamwoorden terug naar werkwoorden (bezig met het controleren ...)
- alvast enkele streepjes na privé weggehaald
- forceren/afdwingen zo gelaten, daar m.i. geen beter alternatief
- losse opmerkingen ook toegepast
- enkele nieuwe dingen in install.it

Dankjewel Laurens voor de tip, latin1 was de oplossing.

Het zou handig zijn als (delen van) deze patch eens zouden toegepast worden, het wordt een beetje onhandelbaar zo (met andere dingen ertussen en te groot)
Attachment #204034 - Attachment is obsolete: true
Attached file Commentaar op att. 204897 (obsolete) — 
Ook maar zo vanwege lengte.
Attachment #204080 - Attachment is obsolete: true
Attachment #205044 - Attachment is patch: false
(In reply to comment #55)
> Created an attachment (id=205044) [edit]
> Commentaar op att. 204897

Sorry dat een antwoord zo lang op ich laat wachten.  Ik heb het wat druk gehad.

Eigenlijk heb ik geen zin meer in deze patch, het ontaardt inderdaad een beetje.  Het lijkt me interessanter van stukken aan te passen als de nood zich voordoet, d.i. als het echt stoort. (mooi hé, die ‘van’, zouden jullie waarschijnlijk nooit zeggen)  Ik zal nog eens een kleinere patch maken van de echte fouten die opgedoken zijn.
(In reply to comment #55)
> Created an attachment (id=205044) [edit]
> Commentaar op att. 204897

Vooral de volgende zin: ‘Ik krijg wel een beetje het gevoel dat het introduceren van 'bezig met' soms iets te ver wordt doorgevoerd, maar dat terzijde.’  Heeft een belletje doen rinkelen, en ik heb dan ook een heleboel dingen teruggedraaid.
Hier alvast de uitleg bij een hele hoop wijzigingen, de patch komt later, maar in stukjes gekapt.  Weggelaten commentaar betekent akkoord of heel anders, zie patch.

> Index: browser/updater/updater.ini
> -Info=Firefox is de updates aan het installeren en zal in een moment starten...
> Dit zou 'uw' worden dacht ik. 

Mag ik het hier oneens zijn?  Ik heb deze ook teruggedraaid, maar wel moment -> ogenblikken.
 

> Index: extensions/reporter/chrome/reportWizard.properties
> ===================================================================
> -sendingReport=Rapport aan het verzenden...
> +sendingReport=Bezig met verzenden van rapport...
> 
> Ook hier is 'aan' niet echt lelijk, maar alla.

Idd, terug.

> Index: toolkit/chrome/global/nsHelperAppDlg.dtd
> ===================================================================
> -<!ENTITY caption.label "Bezig #1 op te halen">
> +<!ENTITY caption.label "Bezig met ophalen van #1">
> 
> Op zich ok, maar volgens mij moet 'ophalen' hier nog 'openen' worden.

Idd.
 
> Index: browser/installer/installer.inc
> -#define MSG_USAGE
> Wellicht dat het eerdere commentaar niet helemaal duidelijk was. Nog maar eens, met wat andere veranderingen (->):
> 
> -> -greLocal: Forceert dat GRE in de programmamap wordt geïnstalleerd.\n

Heb er dit van gemaakt.

> of -greLocal: Forceert/Dwingt GRE (om) te worden geïnstalleerd in de programmamap .\n

Ik snap niet hoe je commentaar kunt geven à la ‘on-Nederlands’ en dan misbaksels van zinnen als dit kunt schrijven.  Dwingen gevolgd door een passieve constructie?!?

-greShared: Forceert dat GRE in een globale, gedeelde map wordt geïnstalleerd, (normaal gesproken)\n
> 			c:\program files\common files\mozilla.org\GRE)\n
> Geen komma, wel haakje verplaatsen (verm. foutje in Engels)

Wel een komma, eigenlijk zou het zelfs een dubbelepunt moeten zijn.  Als je de Engelse nog eens goed leest, dan zul je zien dat dit precies is wat ze bedoelen.

> (+)Dit omzeilt de logica die GRE gebruikt om vast te stellen wanneer het moet worden geïnstalleerd door de installatie
> uit te voeren met een vlag '-f'.
> -> Dit omzeilt GRE's logica van het bepalen wanneer het moet worden geïnstalleerd door de installatie
> uit te voeren met een '-f'-vlag.

Hier vind ik mijn oplossing nog steeds de beste, wel heb ik ‘-f’-vlag aangepast (let op de schuine aanhalingstekens).
 
> (+)* Betekent dat config.ini zal genegeerd worden

'Dat .. zal genegeerd worden' is wel heel erg on-Nederlands. 

Hoezo?  
‘de eenzame bedelaar werd genegeerd’
‘de eenzame bedelaar wordt genegeerd’
‘de eenzame bedelaar zal genegeerd worden’
De hoofdletter is net als in het Engels overigens.

> Index: security/manager/chrome/pippki/pippki.dtd
> ===================================================================
> <!ENTITY downloadCert.message3 "Voordat u deze CA vertrouwt voor enig gebruik dient u haar certificaat te bestuderen, evenals haar beleid en procedures (indien beschikbaar).">
> 
> Graag 'haar'->'zijn' (zul je wel niet leuk vinden).

Idd, maar zoals al eerder aangegeven, ik leg er me bij neer.

De twee kommagevallen in dit bestand vind ik niet echt nodig, die moet je zelf maar eens in een patch gieten, dan kan ik ze daar afschieten.

> Onderdeel?

Goeie.  Ik heb eens een zoek-en-vervang-actie gedaan en overal component door onderdeel vervangen, dat komt er dus in de volgende reeks patches ook door.  (Behalve in de USAGE string hierboven)

> Index: toolkit/installer/windows/install.it
>  MB_ATTENTION_STR=Aandacht
> -> MB_ATTENTION_STR=Attentie
> 
> Had al weg moeten zijn. Was niet leuk om daar achter te komen tijdens setup.. :p
Huh?  Wat is er mis met ‘Aandacht!’ als je om aandacht vraagt?

> Verder is o.a. Windows Taakbeheer in installer.inc nog anders vertaald en hetzelfde geldt voor MSG_FORCE_QUIT_PROCESS, dus als je die allebei nog gelijk kunt maken met deze.

Jij weet beter waar je het over hebt, kan je dit niet zelf eens doen?
 
> Overigens pleit ik sterk voor het hanteren van de vrij normale term 'setup'.

Ik niet.

> Index: toolkit/installer/unix/install.it

> I.i.g. 'locatie' (ev). 'In' een locatie zit me niet lekker en er staat iets bij van een eerdere discussie daarover, of het was iets soortgelijks. Doorgaans installeert men in, op of naar, maar men vertrekt of bevindt zich naar of op een locatie, tenzij 'in de locatie x'. M.a.w., een locatie is een plek/plaats, niet zozeer iets waar iets in kan; bij bv, 'map' bestaat het probleem niet. Daarom maar zo laten.

Ok, ik heb wat zitten zoeken in de Van Dale, daar staat ook een voorbeeld met naar, is hier idd toepasselijker.

> Zie trouwens ook INSTALLFOLDER in windows/install.it.. (Ok, ik wil best ophouden met zeuren over consistentie, maar ga er dan wel vanuit dat je vanaf nu dergelijke wijzigingen eerst globaal checkt..)

Nee, ik kijk altijd naar één zin en probeer die zo optimaal mogelijk te vertalen.  De uitwas die deze patch geworden is is het gevolg van een overdreven zoeken naar consistentie.  Denk je nu echt dat iemand die Firefox op zowel Windows als Unix installeert zich eraan zal storen dat de instructies over de installatiemap een beetje anders verwoord zijn?  Nee, die zal het niet eens merken.
 
> +CXN_DROPPED=Er is een netwerkverbindingsfout opgetreden. Controleer uw netwerkverbinding en druk op de knop ‘Hervatten’ of klik op de knop ‘Annuleren’ om de installatie af te sluiten.
> 
> Jammer dat men hier wel aanhalingstekens bij knoppen gebruikt en elders niet, 

Dat is ook zo in het Engels, maak er een bug van.
(In reply to comment #57)
> > (+)* Betekent dat config.ini zal genegeerd worden
> 
> 'Dat .. zal genegeerd worden' is wel heel erg on-Nederlands. 
> 
> Hoezo?  
> ‘de eenzame bedelaar werd genegeerd’
> ‘de eenzame bedelaar wordt genegeerd’
> ‘de eenzame bedelaar zal genegeerd worden’
> De hoofdletter is net als in het Engels overigens.

Ik weet niet precies wie nou wat hoe wil vertalen, maar:

   "Betekent dat config.ini zal genegeerd worden"

moet toch echt:

   "Betekent dat config.ini genegeerd zal worden"

zijn.


> > Index: toolkit/installer/windows/install.it
> >  MB_ATTENTION_STR=Aandacht
> > -> MB_ATTENTION_STR=Attentie
> > 
> > Had al weg moeten zijn. Was niet leuk om daar achter te komen tijdens setup.. :p
>
> Huh?  Wat is er mis met ‘Aandacht!’ als je om aandacht vraagt?

Attentie is veel beter, als je het mij vraagt. Dat wordt hier in ieder geval meer op die manier gebruikt, als uitroep.


> > Overigens pleit ik sterk voor het hanteren van de vrij normale term 'setup'.
> 
> Ik niet.

Ik ook niet.

Niks mis met installatieprocedure o.i.d.


~Grauw
Hoe zit het eigenlijk met bookmarks.html?  Mijn xml-editor klaagt daar over een ongeldige syntax, en inderdaad zit daar nogal wat fout, maar de html-regels zijn zo slap dat dat op het scherm goed werkt, veronderstel ik.  Ik heb eens alle ontbrekende sluittags ingevoegd, heeft het zin dat ik dat post of niet?
(In reply to comment #58)
> (In reply to comment #57)
> > > (+)* Betekent dat config.ini zal genegeerd worden
> > 
> > 'Dat .. zal genegeerd worden' is wel heel erg on-Nederlands. 
> > 
> > Hoezo?  
> > ‘de eenzame bedelaar werd genegeerd’
> > ‘de eenzame bedelaar wordt genegeerd’
> > ‘de eenzame bedelaar zal genegeerd worden’
> > De hoofdletter is net als in het Engels overigens.
> 
> Ik weet niet precies wie nou wat hoe wil vertalen, maar:
> 
>    "Betekent dat config.ini zal genegeerd worden"
> 
> moet toch echt:
> 
>    "Betekent dat config.ini genegeerd zal worden"
> 
> zijn.

Oeps, weer in de val getrapt, sorry sorry sorry.

Maar nu wel nieuwsgierig, zou je hiermee kunnen leven, want Tonnes gaf heel sterk aan dat dat voor hem niet kan?

> > > Index: toolkit/installer/windows/install.it
> > >  MB_ATTENTION_STR=Aandacht
> > > -> MB_ATTENTION_STR=Attentie
> > > 
> > > Had al weg moeten zijn. Was niet leuk om daar achter te komen tijdens setup.. :p
> >
> > Huh?  Wat is er mis met ‘Aandacht!’ als je om aandacht vraagt?
> 
> Attentie is veel beter, als je het mij vraagt. Dat wordt hier in ieder geval
> meer op die manier gebruikt, als uitroep.

Hm, ergens speelt die sketch van Etienne met het open verhemelte in mijn achterhoofd (Aandaht, aandaht), maar dat zullen jullie daar in het noorden wel niet kennen.  Soit, als het moet; maar verwacht dan niet dat /ik/ die wijziging zal voorstellen...

(In reply to comment #59)
> Hoe zit het eigenlijk met bookmarks.html?  Mijn xml-editor klaagt daar over een
> ongeldige syntax, en inderdaad zit daar nogal wat fout, maar de html-regels
> zijn zo slap dat dat op het scherm goed werkt, veronderstel ik.  Ik heb eens
> alle ontbrekende sluittags ingevoegd, heeft het zin dat ik dat post of niet?

Heh, nee :). HTML is geen XML, dus alles is volledig correct zoals het was. In HTML zijn sluittags op veel plaatsen optioneel, of zelfs niet toegestaan (bijv. bij <img> en <br>) terwijl het bij XML verplicht is, en er zijn wel meer dingen die volgens XML niet mogen en in HTML wel, en andersom.


(In reply to comment #60)
> >    "Betekent dat config.ini zal genegeerd worden"
> > moet toch echt:
> >    "Betekent dat config.ini genegeerd zal worden"
> > zijn.
> 
> Oeps, weer in de val getrapt, sorry sorry sorry.
> 
> Maar nu wel nieuwsgierig, zou je hiermee kunnen leven, want Tonnes gaf heel
> sterk aan dat dat voor hem niet kan?

Ik vind ook wel dat de eerste echt niet kan, ja.


~Grauw
(In reply to comment #61)
> (In reply to comment #59)
> > Hoe zit het eigenlijk met bookmarks.html?  Mijn xml-editor klaagt daar over > Heh, nee :). HTML is geen XML, dus alles is volledig correct zoals het was. In

Tsja, dan zal ik met dat vraagtekentje dat steeds maar verschijnt moeten leren leven...
 
> (In reply to comment #60)
> > >    "Betekent dat config.ini zal genegeerd worden"
> > > moet toch echt:
> > >    "Betekent dat config.ini genegeerd zal worden"
> > > zijn.
> > Maar nu wel nieuwsgierig, zou je hiermee kunnen leven, want Tonnes gaf heel
> > sterk aan dat dat voor hem niet kan?
> Ik vind ook wel dat de eerste echt niet kan, ja.

Ok dat snap ik, maar ik had het zo begrepen dat die hele passieve constructie onaanvaardbaar is, en het dus 
  "Betekent dat het config.ini zal negeren"
moest worden of zo, waar ik die `het´ dan weer zo storend vind.
Besluit ik hieruit dat `genegeerd zal worden´ wel ok is?
(In reply to comment #62)
> Ok dat snap ik, maar ik had het zo begrepen dat die hele passieve constructie
> onaanvaardbaar is, en het dus 
>   "Betekent dat het config.ini zal negeren"
> moest worden of zo, waar ik die `het´ dan weer zo storend vind.
> Besluit ik hieruit dat `genegeerd zal worden´ wel ok is?

Oh, uh... Ik heb geen bezwaar tegen "genegeerd zal worden" nee, en zie ook niet helemaal waarom het anders zou moeten. Maar ik heb mij niet in de argumentatie van Ton verdiept.


~Grauw
Dit pakt een aantal van de ‘bezig met’ gevallen aan, maar op een minder geforceerde manier.  Niet schrikken.  Verder nog andere verbeteringen, zoals 
moment -> even wachten
component(en) -> onderde(e)l(en)
enkele dingen die opgedoken waren bij het bespreken (beruziën) van de vorige patches
en enkele dingen die ik gewoon beter vind.
Attachment #204897 - Attachment is obsolete: true
Attachment #205044 - Attachment is obsolete: true
(In reply to comment #64)
> Created an attachment (id=205891) [edit]
> Wijzigingen in browser, bezig met en andere

De aandachtige waarnemer zal zien dat ik heel subtiel de ‘usage’ string zo gelaten heb, daar is nog wat discussie over.
(In reply to comment #61)
> (In reply to comment #59)
> > Hoe zit het eigenlijk met bookmarks.html?  Mijn xml-editor klaagt daar over een
> > ongeldige syntax, en inderdaad zit daar nogal wat fout, maar de html-regels
> > zijn zo slap dat dat op het scherm goed werkt, veronderstel ik.  Ik heb eens
> > alle ontbrekende sluittags ingevoegd, heeft het zin dat ik dat post of niet?
> 
> Heh, nee :). HTML is geen XML, dus alles is volledig correct zoals het was. In
> HTML zijn sluittags op veel plaatsen optioneel, of zelfs niet toegestaan (bijv.
> bij <img> en <br>) terwijl het bij XML verplicht is, en er zijn wel meer dingen
> die volgens XML niet mogen en in HTML wel, en andersom.

Als ik mijn herwerkte bestand in de browser open, dan ziet het er wel net hetzelfde uit.  (Op een stukje lijn na, dat heb ik blijkbaar niet goed gedaan, maar ik laat het nu maar zo.)  Hoe komt het dat die twee zo ver uit elkaar zijn?  En hou zit het met xhtml, is dat wel geldige xml, of is dat alleen maar html waar een beetje x door gemengd is?
Soortgelijke patch als vorige, hier:
- streepje weg na privé
- kleinere dingetjes n.a.v. eerdere discussie
- bezig met
- component -> onderdeel
+<!ENTITY sendReport.description "Het rapport naar de server aan het zenden...">
omdat ik het vorige niet mooi vond en ik na naspeurwerk in Van Dale tot de conclusie kwam dat zenden hier eigenlijk genoeg zegt.
Attached patch mail (obsolete) — — Splinter Review 
Volgende in het reeksje
- bezig met
- privé
- component
- kleinigheden na discussie
W.b.t. CUSTOM_LONG: de passieve constructie staat me niet zo aan.
(In reply to comment #66)
> Als ik mijn herwerkte bestand in de browser open, dan ziet het er wel net
> hetzelfde uit.  (Op een stukje lijn na, dat heb ik blijkbaar niet goed gedaan,
> maar ik laat het nu maar zo.)  Hoe komt het dat die twee zo ver uit elkaar
> zijn?  En hou zit het met xhtml, is dat wel geldige xml, of is dat alleen maar
> html waar een beetje x door gemengd is?

XHTML is een XML-bewerking van HTML. Toevallig (of misschien niet geheel toevallig :)) is het zo dat als je bij het omzetten naar XML met een aantal regels rekening houdt, beschreven in appendix C van de XHTML specificatie, dat XHTML-bestanden ook correct worden weergegeven door HTML-user agents.

XHTML heeft een aantal voordelen, zoals striktere controle op fouten in browser, dat het met andere namespaces -SVG- gemengd kan worden, en dat het door XML tools -zoals jouw editor- verwerkt kan worden. Maar er zijn ook een aantal nadelen, zo wordt XHTML vaak als text/html geserveerd, dus als ‘tag soup’ HTML verwerkt en alsnog fout geschreven, ook heeft XHTML combineren met andere XML als je het concreet bekijkt nog niet zo heel veel zin, Mozilla rendert XHTML nog niet incrementeel, en een XHTML pagina het moet eigenlijk door XML tools gegenereerd worden en niet door een taal als PHP. Sommige mensen vinden dat de voordelen wel opwegen tegen de nadelen , anderen vinden het tegenovergestelde.

Uiteindelijk is het allemaal niet zo heel belangrijk. Je kan prima XHTML gebruiken voor persoonlijk gebruik als je maar weet waar je mee bezig bent. Maar voor publieke sites waarvan je het beheer uit handen moet geven is het beter om dat niet te doen, tenzij je een XML backend hebt.

In dit specifieke geval is het bookmarks.html bestand een standaardformaat dat ook door andere browsers gebruikt wordt en geimporteerd kan worden, en aangezien het geen direct merkbare voordelen oplevert om XHTML te gebruiken, is het beter om het te laten zoals het is.

Maar goed, deze bug is eigenlijk niet de goede plaats om het hierover te hebben. Ik stel dus voor het hierbij te laten, of te mailen :).


~Grauw
Attached file Commentaar op comment 58-62 (obsolete) — 
Zo maar weer even.

Wederom de vraag: eerst trunk-branch gelijktrekken?
M.b.t. nieuwe spelling,

Ik weet niet of de volgende link al bekend is, maar het volgende document bevat een overzicht van de veranderingen in de nieuwe spelling:

http://taalunieversum.org/taal/spelling/woordenlijst_nederlandse_taal_overzicht_veranderingen.doc

Ik vind de meeste wijzigingen wel goed, alhoewel ik van wijzigingen zoals bas-aria -> basaria niet echt kapot ben (bah, nog meer woorden zoals bommelding, het lijkt wel een biermerk zo). Ook worden er veel rare dingen gecorrigeerd (rampentoerisme -> ramptoerisme), maar ook weer een paar geintroduceerd.

En zo heb ik nog wel een paar aanmerkingen.

Maar goed, over het algemeen dus een nieuwe spelling die we wat mij betreft per direct mogen gaan gebruiken. En dan blijven we lekker dwars bas-aria gewoon lekker als bas-aria schrijven, en instandhouden als instandhouden.


~Grauw
(In reply to comment #71)
> M.b.t. nieuwe spelling,
> Maar goed, over het algemeen dus een nieuwe spelling die we wat mij betreft per
> direct mogen gaan gebruiken. En dan blijven we lekker dwars bas-aria gewoon
> lekker als bas-aria schrijven, en instandhouden als instandhouden.

Heb die lijst nog niet bekeken, maar het hele debat wel van nabij gevolgd, en ben ook over het algemeen wel te spreken over de nieuwe spelling, in tegenstelling tot een hele rist van Nederlandse kranten...  De spelling is pas geldig vanaf januari, maar ik veronderstel dat het nog wel een tijdje duurt eer er een nieuwe release uitkomt, dus we kunnen alvast beginnen.
Euh, nu loop ik achter de feiten: ik ben al begonnen, in de laatste openstaande patches wordt het streepje na privé weggehaald.  Ik denk dat dat de ingrijpendste wijziging van de nieuwe spelling zal zijn op ons werk.

(In reply to comment #70)

> 
> Wederom de vraag: eerst trunk-branch gelijktrekken?
> 

tot en met het moment dat firefox 1.5 uitkwam hebben we de trunk en de branch gelijk kunnen houden.

Er is nu besloten om vanuit de 1.8 branch doortegaan voor versie 2.0. ik zal dus een nieuwe bug openen voor het melden van fouten voor die versie.

de patches in deze bug zal ik na review toepassen op de trunk en de branch. de trunk zal daarna voorlopig niet meer bijgewerkt worden. na de release van 2.0 zal de trunk weer in sync worden gebracht met de branch.

en de nieuwe bug is : #326915
Depends on: 326915
Comment on attachment 206079 [details]
Commentaar op comment 58-62

een discussie die op deze manier gaan kan ik niet meer volgen. ik ga deze discussie dan ook negeren. 

ik stel voor dat er (als het nodig is ) "verbeter" patches worden aangeboden in de nieuwe bug zodat er daar een goede en (en hopelijk) wat compactere discussie gevoerd kan worden.
Attachment #206079 - Attachment is obsolete: true
Depends on: 344502
Comment on attachment 204003 [details] [diff] [review]
karakters -> tekens

ivm met de merge vanuit de branch
Attachment #204003 - Attachment is obsolete: true
Comment on attachment 205891 [details] [diff] [review]
Wijzigingen in browser, bezig met en andere

ivm met de merge vanuit de branch
Attachment #205891 - Attachment is obsolete: true
Comment on attachment 205896 [details] [diff] [review]
wijzigingen in dom, extensions en security

ivm met de merge vanuit de branch
Attachment #205896 - Attachment is obsolete: true
Comment on attachment 205898 [details] [diff] [review]
mail

ivm met de merge vanuit de branch
Attachment #205898 - Attachment is obsolete: true
Assignee: dutch.nl → bugzilla
Status: ASSIGNED → NEW
Hoi allen,

Ik heb na lange tijd nog eens mijn mozilla-bestanden die nog op mijn Windows-schijf staan bekeken, en daar kwam na het nodige updaten en conflicten oplossen deze patch uit.  Een paar dingen zijn misschien controversieel, het meeste lijkt me echter nuttig/mooi.

Oppassen in het eerste bestand van de patch: dit is niet alleen een mooiere uitlijning, er zit in de derde regel ook een verandering in.

Onder andere:
- enkele m.i. mooiere formuleringen
- Firefox -> &brandShortName;
- &#8216;verzenden naar&#8217; is wat dubbelop
- xml ongeldig is wat algemeen, maar kan evt. ook.
- moment -> even wachten
- &#8216;overbodig&#8217; streepje?
- Nog maar eens linker- en rechter- ter discussie stellen: zie http://www.taalpost.nl/texts/archief/pdf/taalpost_462.pdf, onder het motto: de linkerkoptekst is aan de linkerkant als je het blad juist houdt, net als de vergelijking rechter oever vs. rechteroever.
- bezig met X van: een dubbele punt na van komt me wat onnodig voor.
- install.it: weet niet of dit nodig is, of dat Eclipse het gewoon lastig heeft met coderingen.  In welke encoding staat dit ook al weer?
- programmatuur -> software (dit is dus al een meer dan een jaar aanslepende discussie, want zo oud zijn deze wijzigingen, de working directory is zelfs nooit op 1_8-BRANCH geweest...)
- het gebruiken van &euml; enz. is onnodig voor helpteksten, FF kan met unicode omgaan.
- nog een laatste &#8216;component&#8217;
(In reply to comment #80)
> Created an attachment (id=241940) [edit]
> Vanalles, nog op mijn Windows-versie...

Zo op het eerste gezicht zijn er dingen wel enkele dingen die ok zijn, maar andere weer niet. Het lijkt me echter handiger de trunk eerst in sync te (laten) brengen met de branch waar dat nog niet is gebeurd en dan je wijzigingen nog eens na te kijken / voor te stellen.
(In reply to comment #81)
> (In reply to comment #80)
> > Created an attachment (id=241940) [edit]
> > Vanalles, nog op mijn Windows-versie...
> 
> Zo op het eerste gezicht zijn er dingen wel enkele dingen die ok zijn, maar
> andere weer niet.

Ik had niet anders verwacht...  Kan je dan niet de dingen die ok zijn (zoals zeker component, &brandShortName; en moment) alvast toepassen?

> Het lijkt me echter handiger de trunk eerst in sync te
> (laten) brengen met de branch waar dat nog niet is gebeurd

En hoe zie je dit gebeuren?  Kan ik hier iets voor doen?


(In reply to comment #82)
> Ik had niet anders verwacht...  Kan je dan niet de dingen die ok zijn (zoals
> zeker component, &brandShortName; en moment) alvast toepassen?

Punt is dat er (als ik me niet vergis) ondanks een recente synchronisatie-actie van Tim Maks nog steeds verschillen zijn tussen 1_8_branch en trunk, waardoor ik aanneem dat hier nog iets aan moet gebeuren. Dat betekent enerzijds dat enkele van je wijzigingen al vanzelf gaan, en anderzijds zouden sommige juist teniet kunnen worden gedaan. Ik denk dat Tim Maks hier duidelijkheid over kan geven, als hij weer in beeld is. Ook dacht ik dingen te zien die onlangs en na overleg zijn gewijzigd..
Attached file Bericht van OpenTaal (obsolete) — 
Hoi allen, zoals jullie misschien weten werk ik ook een beetje mee aan OpenTaal.  We zijn daar bijna klaar met het samenstellen van een woordenlijst voor spellingcontrole, gecertificeerd door de NTU, en onder Creative Commons, dus volledig integreerbaar met de Nederlandse FF en TB.  Kan iemand die er wat meer ervaring mee heeft daar eens naar kijken of mij instructies geven hoe ik die lijst kan verpakken zodat we die kunnen gebruiken en, liefst, in de standaarddistributie bijvoegen.  Bijgevoegd een mail van Bart Knubben, ייn van de verantwoordelijken van OT.
Volgesn mij is de trunk al lang gelijk aan de branch (de brandshortname fout heb ik nu hersteld) als jullie verschillen zien tussen de branch en de trunk hoor ik dat graag. Als we zeker weten dat de boel gelijk is kunnen we weer patches gaan toepassen om het nogh beter te maken voor Fx 3
Comment on attachment 241940 [details] [diff] [review]
Vanalles, nog op mijn Windows-versie...

Schijnt bij het toepassen toch niet te lukken, slechts één lijntje lukt bij mij.
Attachment #241940 - Attachment is obsolete: true
Attached patch voorlopige patch voor Trunk, FF (obsolete) — — Splinter Review 
Zoals gezegd, graag discussie wat hiervan zinvol is.  Nodig vind ik in ieder geval het vervangen van ... door de Unicode variant.  Ik zal dit ook in en-US voorstellen overigens, op sommige plaatsen doen ze het al.
- de -> het cookie
- ...
(In reply to comment #84)
> Created an attachment (id=243638) [details]
> Bericht van OpenTaal
> Hoi allen, zoals jullie misschien weten werk ik ook een beetje mee aan
> OpenTaal.  We zijn daar bijna klaar met het samenstellen van een woordenlijst
> voor spellingcontrole, gecertificeerd door de NTU, en onder Creative Commons,
> dus volledig integreerbaar met de Nederlandse FF en TB.  Kan iemand die er wat
> meer ervaring mee heeft daar eens naar kijken of mij instructies geven hoe ik
> die lijst kan verpakken zodat we die kunnen gebruiken en, liefst, in de
> standaarddistributie bijvoegen.  Bijgevoegd een mail van Bart Knubben, ייn
> van de verantwoordelijken van OT.

ik heb de maker van het woordenboek op add-ons gevraagd om de versie van opentaal te gaan gebruiken

(In reply to comment #87)
> Created an attachment (id=257127) [details]
> voorlopige patch voor Trunk, FF
> Zoals gezegd, graag discussie wat hiervan zinvol is.  Nodig vind ik in ieder
> geval het vervangen van ... door de Unicode variant.  Ik zal dit ook in en-US
> voorstellen overigens, op sommige plaatsen doen ze het al.

Wat mij betreft wordt dit pas toegepast op de nl versie als het in de en-US versie ook gedaan is.
(In reply to comment #88)
> ik heb de maker van het woordenboek op add-ons gevraagd om de versie van
> opentaal te gaan gebruiken

Ik denk dat om het woordenboek daadwerkelijk mee te leveren (wat wel mooi zou zijn) dat het anders gelicenseerd moet worden, dwz. onder de tri-license?


~Grauw
(In reply to comment #89)
> > Zoals gezegd, graag discussie wat hiervan zinvol is.  Nodig vind ik in ieder
> > geval het vervangen van ... door de Unicode variant.  Ik zal dit ook in en-US
> > voorstellen overigens, op sommige plaatsen doen ze het al.
> 
> Wat mij betreft wordt dit pas toegepast op de nl versie als het in de en-US
> versie ook gedaan is.

Mwa, in en-US gebruiken ze ook geen ’-s, die wij wel gebruiken. Ik ben er voor om inderdaad de typographisch betere …’s te gebruiken, en hier niet mee op en-US te wachten.


~Grauw
(In reply to comment #91)
> (In reply to comment #89)
> > > Zoals gezegd, graag discussie wat hiervan zinvol is.  Nodig vind ik in ieder
> > > geval het vervangen van ... door de Unicode variant.  Ik zal dit ook in en-US
> > > voorstellen overigens, op sommige plaatsen doen ze het al.
> > 
> > Wat mij betreft wordt dit pas toegepast op de nl versie als het in de en-US
> > versie ook gedaan is.
> 
> Mwa, in en-US gebruiken ze ook geen ’-s, die wij wel gebruiken. Ik ben er
> voor om inderdaad de typographisch betere …’s te gebruiken, en hier niet
> mee op en-US te wachten.

Precies zo zie ik het ook, vandaar de patch.

(In reply to comment #90)
> (In reply to comment #88)
> > ik heb de maker van het woordenboek op add-ons gevraagd om de versie van
> > opentaal te gaan gebruiken
> 
> Ik denk dat om het woordenboek daadwerkelijk mee te leveren (wat wel mooi zou
> zijn) dat het anders gelicenseerd moet worden, dwz. onder de tri-license?
> 
> 
> ~Grauw
> 

volgens mij bied mozilla (nog) niet de mogelijkheid om het mee te leveren met de nl build, wel om het aantebieden via de add ons
(In reply to comment #91)

> Mwa, in en-US gebruiken ze ook geen ’-s, die wij wel gebruiken. Ik ben er
> voor om inderdaad de typographisch betere …’s te gebruiken, en hier niet
> mee op en-US te wachten.
> 
wat een kul argument. de ’-s is een taalkundig iets en de ... zijn vormgeving.
(In reply to comment #90)
> (In reply to comment #88)
> > ik heb de maker van het woordenboek op add-ons gevraagd om de versie van
> > opentaal te gaan gebruiken
> 
> Ik denk dat om het woordenboek daadwerkelijk mee te leveren (wat wel mooi zou
> zijn) dat het anders gelicenseerd moet worden, dwz. onder de tri-license?

Er is op dit moment een discussie aan de gang in OpenTaal, over welke licentie we moeten nemen.  De tendens gaat naar zeer liberaal.  Er wordt zeker rekening mee gehouden dat TB die kan integreren.  Als je denkt dat dat niet het geval is, stuur dan eens een commentaar naar Opentaal-discussie@lists.uitwisselplatform.nl, zodat dit in orde komt.

(In reply to comment #94)
> (In reply to comment #91)
> 
> > Mwa, in en-US gebruiken ze ook geen ’-s, die wij wel gebruiken. Ik ben er
> > voor om inderdaad de typographisch betere …’s te gebruiken, en hier niet
> > mee op en-US te wachten.
> > 
> wat een kul argument. de ’-s is een taalkundig iets en de ... zijn
> vormgeving.

Uh?  Wat heeft het verkiezen van ’ boven ' met taalkunde te maken?  Dit is toch louter typografie, net als …?
(In reply to comment #95)

> Uh?  Wat heeft het verkiezen van ’ boven ' met taalkunde te maken?  Dit is
> toch louter typografie, net als …?
> 

ai, dat is een misser van mij, ik had niet in de gaten dat het om de ' ging. ik heb niks gezegd. ! shame !
Is de Opentaal-versie van het woordenboek nu op addons.mozilla.org? Elke keer nadat Firefox op nieuwe versies heeft gecontroleerd krijg ik nu als ik Firefox start een melding dat er een nieuwe versie van het woordenboek is, maar de installatie breekt vervolgens af met de melding dat het niet compatible is met mijn Firefox:

"Nederlands Woordenboek 1.0.4 kon niet worden geïnstalleerd omdat het niet compatibel is met deze versie van Firefox 2.0.0.2. (Nederlands Woordenboek 1.0.4 werkt alleen met Firefox-versies van 2.0.0.* tot 3.0a1)"

De eerste keer was het al een beetje vreemd, maar als hij dit nu om de haverklap blijft doen kan ik zien hoe dit snel irritant wordt. Zeker als dit zich bij iedere gebruiker van het Nederlands woordenboek voordoet.

Verder nog twee gerelateerde vertalingsopmerkingen:

- De frasering "niet compatibel is met deze versie van Firefox 2.0.0.2" is fout, dat moet zijn "niet compatibel is met Firefox 2.0.0.2" of "niet compatibel is met deze versie van Firefox".

- De naam "Nederlands Woordenboek" moet imho toch echt "Nederlands woordenboek" zijn.


~Grauw
(In reply to comment #91)
> (In reply to comment #89)
> > > Zoals gezegd, graag discussie wat hiervan zinvol is.  Nodig vind ik in ieder
> > > geval het vervangen van ... door de Unicode variant.  Ik zal dit ook in en-US
> > > voorstellen overigens, op sommige plaatsen doen ze het al.
> > 
> > Wat mij betreft wordt dit pas toegepast op de nl versie als het in de en-US
> > versie ook gedaan is.
> 
> Mwa, in en-US gebruiken ze ook geen ’-s, die wij wel gebruiken. Ik ben er
> voor om inderdaad de typographisch betere …’s te gebruiken, en hier niet
> mee op en-US te wachten.

Echt nodig vind ik die ... niet (ik zie nauwelijks verschil), maar op zich ben ik niet tegen de invoering ervan. Inderdaad gebeurde dit al soms (!) al in Calendar, maar mede daarom zou ik graag zien dat dit eerst consequent wordt doorgevoerd in en-US. Anders gaan we m.i. te veel een eigen kant op en wordt het voor en-US misschien zelfs vergeten. En als ze daar een goede reden hebben om het te weigeren...

(In reply to comment #97)
> 
> Verder nog twee gerelateerde vertalingsopmerkingen:
> 
> - De frasering "niet compatibel is met deze versie van Firefox 2.0.0.2" is
> fout, dat moet zijn "niet compatibel is met Firefox 2.0.0.2" of "niet
> compatibel is met deze versie van Firefox".

Zit nu in mijn hopelijk laatste patch voor 1_8 die nog volgt. Anders nog iets? ;)

> - De naam "Nederlands Woordenboek" moet imho toch echt "Nederlands woordenboek"
> zijn.

Uiteraard. Taak voor moZes?
Een paar opmerkingen:

In /nl/toolkit/chrome/mozapps/extensions/extensions.properties, bij het activeren van een thema na het klikken op ‘Thema gebruiken’:

   dssSwitchAfterRestart=Herstart %S om ze te gebruiken.

De ‘ze’ hier steekt mij een beetje.

Verder in de volgende bestanden:

   /nl/browser/installer/custom.properties
   /nl/mail/installer/custom.properties
   /nl/calendar/installer/custom.properties

staat de tekst:

   STATUS_CLEANUP=Een kleine schoonmaak...

Dit is zichtbaar tijdens het installeren. Nu stáát er in het Engels ook:

   A Little Housekeeping...
   Cleaning up the birdcage...
   A Little Housekeeping...

Maar toch vind ik het raar. Simpelweg ‘Schoonmaken...’ of beter nog ‘Opruimen...’ doet het mijns inziens beter.

Opinies?


~Grauw
(In reply to comment #99)
> Een paar opmerkingen:

...

> Opinies?

Helemaal mee eens.  Waarom maak je niet gewoon een patch?  (Ik kan het ook bij mij integreren als je wil).
Ik kan een patch maken. Ik hoopde alleen op een suggestie voor de eerste, moet het "Herstart %S om hem te gebruiken." of "Herstart %S om het te gebruiken." zijn... Waarbij het over ‘het thema’ gaat. Mijn taalgevoel laat mij hier een beetje in de steek, sorry.

~Grauw
(In reply to comment #101)
> Ik kan een patch maken. Ik hoopde alleen op een suggestie voor de eerste, moet
> het "Herstart %S om hem te gebruiken." of "Herstart %S om het te gebruiken."
> zijn... Waarbij het over ‘het thema’ gaat. Mijn taalgevoel laat mij hier
> een beetje in de steek, sorry.

Het thema, dus ‘herstart het’, zo simpel is dat.  Ware het nu een de-woord geweest, tsja, dan had ik graag mijn Vlaams taalgevoel bovengehaald...

Overigens kan je zoiets makkelijk even op irc vragen...
Attached patch ze -> het & opruimen (obsolete) — — Splinter Review 
Herstart Firefox/Thunderbird om ze -> het [thema] te gebruiken…
Een kleine schoonmaak... -> Opruimen...

~Grauw
Attached patch Remove excessive capitals. (obsolete) — — Splinter Review 
Wat excessieve hoofdletters verwijderen die erin geslopen zijn.

~Grauw
(In reply to comment #99)
> Een paar opmerkingen:
> 
> In /nl/toolkit/chrome/mozapps/extensions/extensions.properties, bij het
> activeren van een thema na het klikken op ‘Thema gebruiken’:
> 
>    dssSwitchAfterRestart=Herstart %S om ze te gebruiken.
> 
> De ‘ze’ hier steekt mij een beetje.

Ik meen me te herinneren dat deze zin volgt, of voorheen volgde op een meervoudsvorm (".. extensies en thema's zijn geïnstalleerd", of 1 of meer, of enkel 'de updates'?). In dat geval dus zeker 'ze', anders kan het natuurlijk 'het' worden.

> Maar toch vind ik het raar. Simpelweg ‘Schoonmaken...’ of beter nog
> ‘Opruimen...’ doet het mijns inziens beter.

Prima.

(In reply to comment #100)
> 
> Helemaal mee eens.  Waarom maak je niet gewoon een patch?  (Ik kan het ook bij
> mij integreren als je wil).

Niet te veel integreren hoor. Kun je ook om die reden de patch met ... -> [unicode] nog even scheiden van de rest? 

(In reply to comment #102)
> 
> Overigens kan je zoiets makkelijk even op irc vragen...

:-)

(In reply to comment #104)
> Created an attachment (id=259124) [details]
> Remove excessive capitals.
> 
> Wat excessieve hoofdletters verwijderen die erin geslopen zijn.

Was dit geen opzet? Heb in attachment 190700 [details] [diff] [review] de hoofdletters er in gehouden, maar er staat ook iets bij van een korte discussie over hoofdletters in deze en vergelijkbare strings, waar ik nu niet naar heb gezocht. Hier hoofd- of klein maakt me niet veel uit; kleine voorkeur voor groot (opvallende onderdelen) maar in lijn met bv. 'Formaat & opties' is klein ook niet verkeerd, en wellicht toch beter. Hou er wel rekening mee dat deze 3 strings elders ook nog voorkomen, en dan dus mee zouden moeten.

(In reply to comment #105)
> > In /nl/toolkit/chrome/mozapps/extensions/extensions.properties, bij het
> > activeren van een thema na het klikken op ‘Thema gebruiken’:
> > 
> >    dssSwitchAfterRestart=Herstart %S om ze te gebruiken.
> > 
> > De ‘ze’ hier steekt mij een beetje.
> 
> Ik meen me te herinneren dat deze zin volgt, of voorheen volgde op een
> meervoudsvorm (".. extensies en thema's zijn geïnstalleerd", of 1 of meer, of
> enkel 'de updates'?). In dat geval dus zeker 'ze', anders kan het natuurlijk
> 'het' worden.

Nee, dat is niet correct. Probeer het eens in de UI te zien. Ik heb al aangegeven hoe dat moet.

> (In reply to comment #102)
> > 
> > Overigens kan je zoiets makkelijk even op irc vragen...
> 
> :-)

In fact was ik de dag daarvoor op IRC voor iets ongerelateerds, joinde mozilla.nl en maakte nadat er na enige tijd iemand verscheen een opmerking, en ik heb het vervolgens zeker een uur aan laten staan, en ik kreeg geen enkele respons. Ook geen hallo.

Ik heb al tienduizend keer aangegeven dat ik IRC geen fijn medium vind.

Als je een vraag stelt moet in de eerste plaats iemand in het chatkanaal aanwezig zijn die er antwoord op kan geven, en vervolgens moet je net zo lang online blijven totdat je een antwoord krijgt. Als je dat niet krijgt dan is de volgende keer dat je inlogt de vraag allang verdwenen en moet je hem overnieuw stellen en maar hopen dat je dan wel een antwoord krijgt, of dat de aanwezige(n) zich de vraag herinneren en hem alsnog beantwoorden. Zeker nu ik in een andere tijdzone zit (Japan) is dat gewoon niet praktisch. Ten slotte is discussie op IRC een stuk minder gestructureerd, en wordt het ook nergens gearchiveerd (en als dat wel het geval is is het onmogelijk om dingen terug te vinden, probeer maar eens IRC logs van een heel jaar te doorzoeken).

Dus, if you don’t mind, plaats ik liever gewoon een berichtje in Bugzilla.

Ik heb dit al meerdere malen uitgelegd. Dus als het gezeik over mijn niet-gebruik van IRC vanaf nu op kan houden, graag. Het begint mij een beetje (...) te irriteren.

> (In reply to comment #104)
> > Wat excessieve hoofdletters verwijderen die erin geslopen zijn.
> 
> Was dit geen opzet? Heb in attachment 190700 [details] [diff] [review] de hoofdletters er in gehouden,
> maar er staat ook iets bij van een korte discussie over hoofdletters in deze en
> vergelijkbare strings, waar ik nu niet naar heb gezocht. Hier hoofd- of klein
> maakt me niet veel uit; kleine voorkeur voor groot (opvallende onderdelen) maar

Of het al dan niet expres is maakt het nog niet correct :). Het lijkt mij duidelijk een overblijfsel van en-US. In het Nederlands worden er zelden hoofdletters gebruik als het niet een naam of aan het begin van een zin is. Dit lijkt mij geen uitzondering (en al helemaal geen voorkeurgeval). Bovendien, elders wordt er ook gewoon een kleine letter gebruikt. Bijv. Lettertypen & kleuren op de Inhoud-tab van Opties.


~Grauw
(In reply to comment #106)
> > (In reply to comment #102)
> > > 
> > > Overigens kan je zoiets makkelijk even op irc vragen...
> > 
> > :-)
> 
> In fact was ik de dag daarvoor op IRC voor iets ongerelateerds, joinde
> mozilla.nl en maakte nadat er na enige tijd iemand verscheen een opmerking, en
> ik heb het vervolgens zeker een uur aan laten staan, en ik kreeg geen enkele
> respons. Ook geen hallo.
> 
> Ik heb al tienduizend keer aangegeven dat ik IRC geen fijn medium vind.

...

Oeps, sorry.

> > (In reply to comment #104)
> > > Wat excessieve hoofdletters verwijderen die erin geslopen zijn.
> Of het al dan niet expres is maakt het nog niet correct :). Het lijkt mij
> duidelijk een overblijfsel van en-US. In het Nederlands worden er zelden
> hoofdletters gebruik als het niet een naam of aan het begin van een zin is. Dit
> lijkt mij geen uitzondering (en al helemaal geen voorkeurgeval). Bovendien,
> elders wordt er ook gewoon een kleine letter gebruikt. Bijv. Lettertypen &
> kleuren op de Inhoud-tab van Opties.

Helemaal mee eens.  Goede patch.
(In reply to comment #106)
> (In reply to comment #105)
> > Ik meen me te herinneren dat deze zin volgt, of voorheen volgde op een
> > meervoudsvorm (".. extensies en thema's zijn geïnstalleerd", of 1 of meer, of
> > enkel 'de updates'?). In dat geval dus zeker 'ze', anders kan het natuurlijk
> > 'het' worden.
> 
> Nee, dat is niet correct. Probeer het eens in de UI te zien. Ik heb al
> aangegeven hoe dat moet.

Ja da's duidelijk. Punt was dat dit het enige gebruik ervan moet zijn, in orde dus.

> > Was dit geen opzet? Heb in attachment 190700 [details] [diff] [review] [details] de hoofdletters er in gehouden,
> > maar er staat ook iets bij van een korte discussie over hoofdletters in deze en
> > vergelijkbare strings, waar ik nu niet naar heb gezocht. Hier hoofd- of klein
> > maakt me niet veel uit; kleine voorkeur voor groot (opvallende onderdelen) maar
> 
> Of het al dan niet expres is maakt het nog niet correct :). Het lijkt mij
> duidelijk een overblijfsel van en-US. In het Nederlands worden er zelden
> hoofdletters gebruik als het niet een naam of aan het begin van een zin is. 

Ja dat hoef je mij niet uit te leggen en ik denk er ook zo over, vandaar de conclusie (in het net niet gequote of nog niet gelezen deel :)).

> Dit
> lijkt mij geen uitzondering (en al helemaal geen voorkeurgeval). Bovendien,
> elders wordt er ook gewoon een kleine letter gebruikt. Bijv. Lettertypen &
> kleuren op de Inhoud-tab van Opties.

Precies wat ik bedoelde met het andere voorbeeld. Ok dus, maar let op de andere verschijningen. Nieuwe patch?

Hoi!

De als in de zinnen in deze patch komt een beetje vreemd over. Zodra lijkt me hier beter, en op een andere plaats (wanneer de actie nog niet is gedaan) wanneer.

Voor de duidelijkheid, deze melding krijg je als je bij een geïnstalleerde add-on op ‘deïnstalleren’ klikt.

Hopelijk zijn jullie het met mij eens, commentaar graag :).


~Grauw
Attached patch Remove excessive capitals (obsolete) — — Splinter Review 
Zoals door Ton gevraagd, een nieuwe patch die consistent alle hoofdletters na een & vervangt door een kleine letter. Hopelijk heb ik alle voorkomens gevonden (gezocht met reguliere expressies ‘& [A-Z]’ en ‘&amp; [A-Z]’).

Groet!


~Grauw
Attachment #259124 - Attachment is obsolete: true
(In reply to comment #110)
> Created an attachment (id=260449) [details]
> Remove excessive capitals
> 
> Zoals door Ton gevraagd, een nieuwe patch die consistent alle hoofdletters na
> een & vervangt door een kleine letter. Hopelijk heb ik alle voorkomens gevonden
> (gezocht met reguliere expressies ‘& [A-Z]’ en ‘&amp; [A-Z]’).

In am-smime.properties zou ik ook alle ‘E-mail- & ’ met kleine e schrijven: deze staan midden in een zin, geen reden voor hoofdletters.

Analoog hier:

+<!ENTITY rContent2 "Dubbel-klik de categorie om de lijst uit te klappen, indien geen subcategorieën zichtbaar zijn aan de linkerkant onder privacy &amp; veiligheid.">

en vooral ook die ‘e’ in subcategorieën invoegen!!

En hier moet het waarschijnlijk ‘beveiliging’ worden?

+<!ENTITY popupNote1.label "Open het menu Bewerken en kies Voorkeuren, om voorkeuren in te stellen voor het controleren van pop-ups. Klik op Pop-ups, onder de categorie Privacy &amp; beveiliging.">

Andere patch is goed, trouwens.
Ja, dat heb ik expliciet allemaal niet gewijzigd en dat mag in een andere patch, als het al gewenst is.

Reden is dat verwijzingen naar menu-opties overal met een hoofdletter worden geschreven. M.a.w. dan zou dat op heel veel plaatsen kleine letters moeten worden, en ik weet niet of dat een goed idee is. De functie van de hoofdletters is dat ze aanduiden dat het om een menu-optie gaat en niet om een onderdeel van de tekst zelf, en dat zou je dan verliezen.

Maar als je vind dat het nodig is en een patch ervoor maakt, dan geef ik daar graag mijn mening over :).


~Grauw
Att 257157 zie ik graag nog gesplitst in ... -> Unicode ... en de rest. Het scheelt niet veel maar toch, en is wellicht handig om de ...-wijziging terug te draaien bij problemen, of later toe te passen nadat dit ook in en-US is gebeurd.

Att 258786 bevat ook +STATUS_CLEANUP=Opruimen\U2026 voor calendar, die inmiddels al is gewijzigd. Deze eraf knippen ter voorkoming van hunks?

OK voor att 260448. Hoewel ik nogal oplettend ben waar het gaat om vertaling van if en when heb ik deze whens meen ik bewust als 'als' vertaald, maar wellicht is wanneer toch beter, bovenin althans. Onder ziet 'zodra' er logischer uit, zelfs beter dan 'wanneer'.

Att 260449 kan ook wel, al zou je inderdaad ook dingen als 'met met', dubbelklik (zonder -), de genoemde e en smartcards kunnen meenemen. Maar dat kan ook later, e.e.a. zal wellicht nog wijzigen. (Zou het zelf wel meteen doen, en erbij vermelden). Verwijzingen naar menuopties inderdaad liever/gewoon met hoofdletters.

Happy Easter. ;)
(In reply to comment #113)
> Att 258786 bevat ook +STATUS_CLEANUP=Opruimen\U2026 voor calendar, die
> inmiddels al is gewijzigd. Deze eraf knippen ter voorkoming van hunks?

Dat kan Tim doen tijdens het committen, neem ik aan?

> Att 260449 kan ook wel, al zou je inderdaad ook dingen als 'met met',
> dubbelklik (zonder -), de genoemde e en smartcards kunnen meenemen.

Ik heb alleen naar de hoofdletters gezocht, en verder niet de strings uitgebreid bekeken :).


~Grauw
Depends on: 372370
Hoi allen,
Ik heb me de laatste tijd bezig gehouden de trunk en branch te vergelijken.  Hier volgt een patch die probeert alles gelijk te trekken tussen de twee.  Natuurlijk zijn dingen die in één van de twee erbij gekomen dan wel verdwenen zijn, hier ook niet aanwezig.  Er zijn ook enkele nieuwe vertalingen bij.

Ik moet jammer genoeg toegeven, dat er ook al eens iets bij zit dat nieuw van mij is.  Bijv. het vervangen van een aantal streepjes door n-dashes (in browser/installer/installer.inc) en andere Unicode-gerelateerde vervangingen (©). En Postvak In.  En nog een paar.  Het is gewoon te verwarrend en te lang geleden om precies te weten wat van mij is en wat niet.  Gelieve er de zinvolle dingen uit te liften. (Ik vind alles zinvol...)

Er zitten ook een paar accesskeys bij.  Ton: kan jij eens controleren of die wel moeten?

Deze patch gaat uiteraard vergezeld van een tweeling voor de branch, maar ik geloof dat het toch geen zin meer heeft die nog te posten?

Het is nogal een groot ding nu, kijk er even naar, en dan ben ik bereid aanpassingen door te voeren en op te splitsen.
(In reply to comment #115)
> 
> Er zitten ook een paar accesskeys bij.  Ton: kan jij eens controleren of die
> wel moeten?

Ik zal zeker naar de keys kijken maar zal dat pas over enkele dagen kunnen doen.

> Deze patch gaat uiteraard vergezeld van een tweeling voor de branch, maar ik
> geloof dat het toch geen zin meer heeft die nog te posten?

De meeste zaken die zijn ingekort in de laatste patch voor TB2 beschouw ik als zinvol, en 1 dubbele key zit me erg dwars. Wellicht dat er eerdaags nog iets vervelends bijkomt dat ruimte biedt voor een kleine fixbug waarin e.e.a. nog kan worden bijgeplaatst.. En was het niet de bedoeling dat er vaker een of meer korte periodes zouden zijn voor kleine l10n-fixes in 2.x.x.x (FF+TB)?

> Het is nogal een groot ding nu, kijk er even naar, en dan ben ik bereid
> aanpassingen door te voeren en op te splitsen.

Niet schrikken; een snelle blik leert dat de patch inderdaad een verzameling is van persoonlijke voorkeuren, soms wat Vlaams aandoende termen en zinsbouw (incl. groene stijl), dingen die key-conflicten kunnen opleveren, het alsnog doorvoeren van langeafstandsloper-gevallen en wat Help-wijzigingen (incl. UTF-8 daarin?). Voor een indruk is hij nuttig, maar zoals je al aangaf is scheiden van de zaken een stuk handiger. Let s.v.p. wel op dingen die al eerder zijn gewijzigd, zowel in keys als tekst. En wat te doen met de nog staande patches?

Persoonlijk zou ik liever eerst een of meer correctieacties zien vanaf het moment van splitsen van 1_8_branch (ofwel van alles wat daarna nog is gewijzigd in trunk), gevolgd door een synchronisatie-actie met de 1_8_branch (of andersom) en pas als laatste 'nieuwe' wijzigingen als deze gaan voorstellen, gesplitst in type wijziging. Maar dat is enkel mijn voorkeur, t.b.v. overzicht en foutherkenning.

Comment on attachment 263909 [details] [diff] [review]
Patch om trunk en branch gelijk te trekken

deze patch bevat o.a. ook calender en suite dingen, deze hebben hun eigen bug. graag een nieuwe maken die actueel is (en meer in stukken zodat, zoals nu, niet alles in eenkeer afgekeurd word)
Attachment #263909 - Attachment is obsolete: true
Attachment #263909 - Flags: review-
Comment on attachment 257127 [details] [diff] [review]
voorlopige patch voor Trunk, FF

Zie comment #113
Attachment #257127 - Attachment is obsolete: true
Comment on attachment 258786 [details] [diff] [review]
ze -> het & opruimen

toegepast zonder :
-dssSwitchAfterRestart=Herstart %S om ze te gebruiken.
+dssSwitchAfterRestart=Herstart %S om het te gebruiken.

er kunnen ook meerdere thema's / extensies geinstalleerd zijn.
Attachment #258786 - Attachment is obsolete: true
Comment on attachment 260448 [details] [diff] [review]
Vervang ‘als’ door ‘zodra’ en ‘wanneer’

toegepast
Attachment #260448 - Attachment is obsolete: true
Comment on attachment 260449 [details] [diff] [review]
Remove excessive capitals

toegepast
Attachment #260449 - Attachment is obsolete: true
Depends on: 357099
(In reply to comment #119)
> (From update of attachment 258786 [details] [diff] [review])
> toegepast zonder :
> -dssSwitchAfterRestart=Herstart %S om ze te gebruiken.
> +dssSwitchAfterRestart=Herstart %S om het te gebruiken.
> 
> er kunnen ook meerdere thema's / extensies geinstalleerd zijn.

Nee. Onjuistheden:

1. Dit wordt alleen bij thema’s gebruikt.
2. Er kan slechts één thema geactiveerd zijn.
3. Dit word afzonderlijk op het geactiveerde thema weergegeven.

Ik heb dit al sinds 2007-03-16 aan de orde gesteld, en zowel Henrik als Ton hebben hier een review van gedaan, waar ik zonodig weer een reactie op heb gegeven.

Dus graag alsnog toepassen, en wijzigingen niet weglaten zonder een goede reden. Dank.


~Grauw
Voor de duidelijkheid, deze string verschijnt als je in de Thema’s tab van het Add-ons-venster op de knop ‘Thema gebruiken’ klikt.
(In reply to comment #122)
> (In reply to comment #119)
> > (From update of attachment 258786 [details] [diff] [review] [details])
> > toegepast zonder :
> > -dssSwitchAfterRestart=Herstart %S om ze te gebruiken.
> > +dssSwitchAfterRestart=Herstart %S om het te gebruiken.
> > 
> > er kunnen ook meerdere thema's / extensies geinstalleerd zijn.
> 
> Nee. Onjuistheden:
> 
> 1. Dit wordt alleen bij thema’s gebruikt.
> 2. Er kan slechts één thema geactiveerd zijn.
> 3. Dit word afzonderlijk op het geactiveerde thema weergegeven.
> 
> Ik heb dit al sinds 2007-03-16 aan de orde gesteld, en zowel Henrik als Ton
> hebben hier een review van gedaan, waar ik zonodig weer een reactie op heb
> gegeven.
> 
> Dus graag alsnog toepassen, 

Ok, ik heb er nog een keer naar gekeken en de string in de ui zien verschijnen, je hebt gelijk! ik zal de wijziging doorvoeren

> en wijzigingen niet weglaten zonder een goede
> reden. Dank.

Ik heb altijd een goede reden, al kan dat soms niet de juiste zijn. graag een beetje normaal reageren!

> Ik heb altijd een goede reden, al kan dat soms niet de juiste zijn.

Die heb je dan gevormd zonder naar de input van Henrik en Tom (en uiteraard ook die van mij) te kijken, noch naar hoe de string in Firefox verschijnt.

> graag een beetje normaal reageren!

Wel sorry.

Maar de patch lag er al 2 maanden, met vrij uitgebreid commentaar. Dus je kan het me toch niet kwalijk nemen dat ik een beetje verontwaardigd ben als er 1. ruim voldoende tijd is geweest om er dergelijk commentaar op te geven en 2. hij pas 2 maanden later wordt ingechecked, en dan onvolledig.

Ik bedoel, die 2 maanden heb ik op zich geen problemen mee, het heeft geen haast ofzo, en ik begrijp ook dat je dit in je vrije tijd doet als vrijwilliger.

Maar dat geldt ook voor mij, en als ik in een 2-maanden oude patch van mij mag gaan duiken om vervolgens een reactie te schrijven waarin ik enkel verwijs naar eerdere reacties (Ton heeft praktisch dezelfde vraag eerder gesteld) en de begeleidende tekst van mijn oorspronkelijke attachment herhaal, dan vind ik dat ook niet leuk. Ik bedoel, zoek even op hoe het in de UI verschijnt, of check het gewoon in als je weet dat Ton en Henrik hun OK eraan gegeven hebben, en ik ook.


~Grauw
Bij de weg,

Als ik een beetje bitcherig or nors overkom, neem het alsjeblieft met twee korrels zout. Als ik ergens verontwaardigd over ben probeer ik om dat niet al te veel door te laten schemeren in wat ik schrijf, maar in welke mate ik daarin slaag varieert. Daar dus mijn verontschuldigingen voor, maar ook een beetje begrip gevraagd. Denk maar gewoon oh het is die Laurens weer ofo :).

Uiteraard waardeer ik de tijd en moeite die je erin steekt, en ben ik blij dat het uiteindelijk allemaal is ingechecked.


~Grauw
Ik wou jullie gewoon even het (wat mij betreft) heugelijke nieuws mededelen dat FF vanaf nu overal in menu’s de echte ellipsis zal gaan gebruiken, en geen drie puntjes, zie bug 390333, bug 390282, bug 373623.  Niets houdt ons dus nog tegen eindelijk mijn patch door te voeren waarin ook bij ons de puntjes ingevoerd worden.
Kijk aan, het is je gelukt. Als ik zo de verschillende bugs bekijk is het maar goed dat ik even terughoudend was maar nu het doorgevoerd wordt zal ik het zeker ook doen :-). Maak jij een patch ( ik zal dit weekend er ook naar kijken en als ik tijd genoeg heb zal ik het zelf doen)
(In reply to comment #128)
> Kijk aan, het is je gelukt. Als ik zo de verschillende bugs bekijk is het maar
> goed dat ik even terughoudend was maar nu het doorgevoerd wordt zal ik het
> zeker ook doen :-). Maak jij een patch ( ik zal dit weekend er ook naar kijken
> en als ik tijd genoeg heb zal ik het zelf doen)

Bedankt :-)

Ja, er is zeker een nieuwe patch nodig.  Ik ben echter de komende drie weken in het buitenland, kan er dus niet aan werken.  Vanavond krijg ik dat niet meer gedaan.  Dus als je het zelf wil doen: graag, anders moet het maar even wachten.

Nu nog de mensen van WikiMedia zo ver krijgen om dit ook te doen... (mijn bug werd daar vrij vlug invalid verklaard).
Met de bijbedoeling om FF3a7 werkend en taalkundig in orde te maken (waarvoor nu te laat) heb ik de afgelopen week alle wijzigingen in de trunk over de periode 09/2006 t/m 07/2007 nagelopen en dit is eruit gerold, met hier en daar een kleine extra wijziging. Aanpassingen voor de mailbestanden volgen nog, evenal nsserrors.properties in zijn geheel en resterende strings in pipnss.properties.

Tim Maks: kun jij xslt.properties even controleren, aangezien daarmee hetzelfde probleem schijnt te bestaan als eerder maandenlang met een bookmarkbestand (line endings, 0x0A etc.) waardoor het niet te bewerken is na ophalen met Tortoise. Verder een vriendelijk verzoek niet te lang te wachten met toepassen, of dit in ieder geval te doen vóór de ... naar unicode-wijziging, om begrijpelijke redenen. ;)
Comment on attachment 275337 [details] [diff] [review]
Correcties en wijzigingen FF/toolkit t/m 31/07

Een mooie patch, is nu toegepast op de trunk, bedankt.
p.s het staat me bij dat we tags als labels zouden vertalen)
Attachment #275337 - Attachment is obsolete: true
Hetzelfde verhaal voor TB. Ook hier en daar wat consistentiezaken, o.a. verificatie/authenticatie e.a. en nog enkele kleinigheidjes voor FF.

(In reply to comment #131)
> p.s het staat me bij dat we tags als labels zouden vertalen) 

Klopt, maar dat geldt dan voor labels zoals we die aan e-mailberichten hangen. Het begrip Metatag is een term die we denk ik beter intact kunnen laten; deze wordt vrijwel nooit vertaald als metalabel o.i.d. Zie ook http://nl.wikipedia.org/wiki/Metatag.

(In reply to comment #130)
> probleem schijnt te bestaan als eerder maandenlang met een bookmarkbestand
> (line endings, 0x0A etc.) waardoor het niet te bewerken is na ophalen...

Dat bookmarkbestand moest natuurlijk addressBook.properties zijn.

Zijn wijzigingen voor SM hier overigens ook toegestaan, of liever in de eigen bugs?
(In reply to comment #132)

> Zijn wijzigingen voor SM hier overigens ook toegestaan, of liever in de eigen
> bugs?
> 
liever zo veel mogelijk in de eigen bugs, maar als er bijvoorbeeld bestanden aangepast worden die vervolgens ook aangepast moeten worden in Fx of Tb is hier beter...... 

Comment on attachment 276387 [details] [diff] [review]
Correcties en wijzigingen TB t/m 08/08

toegepast op de trunk
Attachment #276387 - Attachment is obsolete: true
Nog een paar dingetjes voor hoofdzakelijk TB die zijn weggelaten in mijn laatste patch voor TB 2.

> (In reply to comment #132)
> 
> > Zijn wijzigingen voor SM hier overigens ook toegestaan, of liever in de eigen
> > bugs?
> > 
> liever zo veel mogelijk in de eigen bugs, maar als er bijvoorbeeld bestanden
> aangepast worden die vervolgens ook aangepast moeten worden in Fx of Tb is hier
> beter...... 

Ok. En andersom, dus als voor TB iets wijzigt dat wellicht meekan in SM (zoals in deze)?
(In reply to comment #135)

> Ok. En andersom, dus als voor TB iets wijzigt dat wellicht meekan in SM (zoals
> in deze)?
>

Graag ook de aanpassingen voor seamonkey meenemen :-)
Idem als de vorige, incl. 2 kleine dingen (in askSendformat) maar dan ook voor SM, waarvoor ook aangepaste keys en opmaak.
Attachment #277244 - Attachment is obsolete: true
Attached patch Werkbalk Snel starten e.a. (obsolete) — — Splinter Review 
Consistentie in 'Werkbalk Snel starten' en {bsn} Veilige modus voor FF/TB/Cal/SM, en zijnde->als (bug 355220).
(In reply to comment #127)
> Ik wou jullie gewoon even het (wat mij betreft) heugelijke nieuws mededelen dat
> FF vanaf nu overal in menu’s de echte ellipsis zal gaan gebruiken, en geen
> drie puntjes, zie bug 390333, bug 390282, bug 373623.  Niets houdt ons dus nog
> tegen eindelijk mijn patch door te voeren waarin ook bij ons de puntjes
> ingevoerd worden.

Hoezee! Ook mooi dat dit nu in alle talen komt!
(In reply to comment #130)

> Tim Maks: kun jij xslt.properties even controleren, aangezien daarmee hetzelfde
> probleem schijnt te bestaan

is het nu goed?


(In reply to comment #140)
> 
> is het nu goed?

Nope..
Attached file xslt.properties (obsolete) — 
Zo dan? Woordvolgorde in regel 27 ook iets aangepast.
Comment on attachment 279462 [details]
xslt.properties

bestand vervangen
Attachment #279462 - Attachment is obsolete: true
Comment on attachment 277299 [details] [diff] [review]
resterende zaken die TB2 net niet haalden v2

toegepast
Attachment #277299 - Attachment is obsolete: true
Comment on attachment 277416 [details] [diff] [review]
Werkbalk Snel starten e.a.

toegepast
Attachment #277416 - Attachment is obsolete: true
Comment on attachment 243638 [details]
Bericht van OpenTaal

de opentaalwoordenijst wordt nu gebruikt https://bugzilla.mozilla.org/show_bug.cgi?id=383855
Attachment #243638 - Attachment is obsolete: true
Attached patch Downloadstrings (obsolete) — — Splinter Review 
Iets betere downloadstrings, trekt deze ook gelijk met SB.
Comment on attachment 279791 [details] [diff] [review]
Downloadstrings

toegepast
Attachment #279791 - Attachment is obsolete: true
Deze patch vervangt alle ... door unicode ellipsis, en verder alle \u-entiteiten in .properties-bestanden door hun Unicode variant.  Hoewel .properties-bestanden officieel in iso-8859-1 zijn, gebruikt Mozilla intern UTF-8.  Ik heb met Pike hierover gesproken, het is ok.  De wijzigingen in de Engelse trunk laten nog wat op zich wachten, omdat ik er eerst in moet slagen de programma’s zelf te compileren om de patches te testen, maar ze zijn in principe al goedgekeurd.

Ik heb mijn best gedaan de andere wijzigingen eruit te halen, als er ergens iets niet werkt of door de mazen van het net geglipt is, laat het met dan weten.

Verder ook wat spaties en nieuwe lijnen etc.

Gezien dit ondertussen dingen zijn die niet echt meer ter discussie staan, graag snel uitvoeren, zodat ik mijn andere wijzigingen ook kan posten.
Attached patch kleine patch voor witruimte (obsolete) — — Splinter Review 
uitlijnen van twee bestandjes, zoals het in en ook is
(In reply to comment #130)
> Created an attachment (id=275337) [details]
> Correcties en wijzigingen FF/toolkit t/m 31/07

mooie patch inderdaad.  Het heeft even geduurd voordat ik tijd heb gevonden hiernaar te kijken.  Enkele verbeteringen heb ik nog, maar die zal ik dan wel in een nieuwe patch gieten, als de puntjes in orde zijn (anders is het veel te moeilijk de dingen te scheiden).

Een vraagje is opgedoken: willen we ‘allow’ vertalen als toestaan of toelaten?  Ik vind het tweede iets vriendelijker klinken.  Wat denken jullie?

(In reply to comment #132)
> Created an attachment (id=276387) [details]
> Correcties en wijzigingen TB t/m 08/08

Toch graag patches die alleen maar formatteren scheiden van echte wijzigingen.  Anders wordt het zo onoverzichtelijk (ik was hier in het verleden ook niet onschuldig aan, maar heb het toch leren waarderen...)

Dankzij Ton nog een string gevonden waarin niet alleen de puntjes en spaties aangepast werden.  Deze nog eens helemaal gecontroleerd (en effectief nog 2-3 echte wijzigingen gevonden), zou zonder bedenken toepasbaar moeten zijn.
Ook install.it eruit, daar dat toch maar problemen oplevert.  Voor alle duidelijkheid: ik ben nu zeker dat het in cp1252 moet zijn, maar dat laat geen ellipsis toe, dus daar blijven de puntjes.
Attachment #280197 - Attachment is obsolete: true
(In reply to comment #152)
> Ook install.it eruit, daar dat toch maar problemen oplevert.  Voor alle
> duidelijkheid: ik ben nu zeker dat het in cp1252 moet zijn, maar dat laat geen
> ellipsis toe, dus daar blijven de puntjes.

Wel hoor, … is code point 133 in cp1252, zie: http://en.wikipedia.org/wiki/Cp1252

Overigens: de code page is ook niet cp1252, het is de non-unicode code page van het systeem. M.a.w., als ik Japans als code page instel omdat ik een Japans spel wil spelen ofzo, dan krijg ik allerlei rare tekens waar er accenten staan in de installatieschermen van Firefox. Op een doorsnee Nederlandse Windows-installatie is het echter meestal inderdaad cp1252. Desalniettemin, als je Unicode escape-codes op kunt geven dan verdient dat natuurlijk de voorkeur (ik ben even vergeten of dat nou wel of niet kon in install.it).
(In reply to comment #153)
> (In reply to comment #152)
> > Ook install.it eruit, daar dat toch maar problemen oplevert.  Voor alle
> > duidelijkheid: ik ben nu zeker dat het in cp1252 moet zijn, maar dat laat geen
> > ellipsis toe, dus daar blijven de puntjes.
> 
> Wel hoor, … is code point 133 in cp1252, zie:
> http://en.wikipedia.org/wiki/Cp1252

Ah goed, dan zal ik daarvoor nog een aparte patch maken.  Overigens heb ik ondertussen gemerkt dat ik nog een paar puntjes vergeten ben, en überhaupt de hele map suite/, dus daarvoor komt dan ook nog een patch.  Tim: mag ik die hier hangen, of waar dan wel?

> Overigens: de code page is ook niet cp1252, het is de non-unicode code page van
> het systeem. M.a.w., als ik Japans als code page instel omdat ik een Japans
> spel wil spelen ofzo, dan krijg ik allerlei rare tekens waar er accenten staan
> in de installatieschermen van Firefox. Op een doorsnee Nederlandse
> Windows-installatie is het echter meestal inderdaad cp1252.

Juist, en daar wij Nederlands gebruiken is het belangrijkste voor ons, dat install.it *bij ons* altijd in cp1252 hoort te zijn.

> Desalniettemin, als
> je Unicode escape-codes op kunt geven dan verdient dat natuurlijk de voorkeur
> (ik ben even vergeten of dat nou wel of niet kon in install.it).

Ik geloof het niet.

(In reply to comment #153)
(cp1252)
<{KaiRo}>  Cedric: oh, so it's supposed to be whatever encoding Windows uses for your language?
<{Cedric}>  yes
<{Hamaryns}>  can I find out in lxr what encoding is used
<{Cedric}>  I recall there is a page indicating which encoding should be used for that file regarding the language
<{KaiRo}>  Cedric: good, this should definately be up in some L10n doc at MDC
<{Hamaryns}>  ok, that’ll be cp1252 as well for us
<{Cedric}>  I found it : --> {http://developer.mozilla.org/en/docs/Encodings_for_localization_files}

Lijkt me duidelijk? (Dit is ook al eerder voorbij gekomen, zie comment 48 e.v.)

(In reply to comment #154)
> Ah goed, dan zal ik daarvoor nog een aparte patch maken.  Overigens heb ik
> ondertussen gemerkt dat ik nog een paar puntjes vergeten ben, en überhaupt de
> hele map suite/, dus daarvoor komt dan ook nog een patch.  Tim: mag ik die hier
> hangen, of waar dan wel?

De suite vergeten? Niet overmoedig worden hoor ;) Maar wel een goede vraag; ik heb een aantal bestanden voor SM 2 staan waarvan ik nog niet weet wat ermee te doen aangezien deze nog geen eigen bug heeft. Daarnaast was mijn intentie zoals gezegd (op irc) eerdere correcties als die voor FF/TB ook apart op SM toe te passen en vanaf dan met dezelfde regelmaat mee te nemen, gevolgd door nalopen van de hele suite, waar nog behoorlijk wat aan scheelt. Uiteraard is de bijbedoeling om te 'backporten' naar 1.1.x indien mogelijk, en omgekeerd fouten in 1.1.x mee te nemen in 2.

Een toegevoegde SM-vraag: blijven wijzigingen voor 1.1.x alleen in bestandsvorm mogelijk, aangezien die niet in cvs staat? Zo ja dan wordt dat een drukke bug, tenzij aanleveren op een andere manier mogelijk is.

Comment on attachment 280254 [details] [diff] [review]
versie met echt alleen maar onschuldige dingen

zou de patch nog een keer kunnen maken :
patch: **** malformed patch at line 963: Index: mail/chrome/messenger/importDialog.dtd

ik weet niet wat er mis gaat.....
Attachment #280254 - Attachment is obsolete: true
Attached patch verbeterde patch (obsolete) — — Splinter Review 
Dat kwam doordat ik de patch met de hand heb bijgewerkt.  Ik heb er het foutje uigehaald, weer met de hand.  Als er nog zo een in zit, dan maak ik een nieuwe gebaseerd op een verse checkout.
(In reply to comment #157)
> Created an attachment (id=280454) [details]
> verbeterde patch
> 
> Dat kwam doordat ik de patch met de hand heb bijgewerkt.  Ik heb er het foutje
> uigehaald, weer met de hand.  Als er nog zo een in zit, dan maak ik een nieuwe
> gebaseerd op een verse checkout.
> 

patch: **** malformed patch at line 1377: Index: mail/chrome/messenger/outlookImportMsgs.properties
Comment on attachment 280454 [details] [diff] [review]
verbeterde patch

Toegepast
Attachment #280454 - Attachment is obsolete: true
Comment on attachment 280198 [details] [diff] [review]
kleine patch voor witruimte

toegepast
Attachment #280198 - Attachment is obsolete: true
(In reply to comment #155)

> De suite vergeten? Niet overmoedig worden hoor ;) Maar wel een goede vraag; ik
> heb een aantal bestanden voor SM 2 staan waarvan ik nog niet weet wat ermee te
> doen aangezien deze nog geen eigen bug heeft. Daarnaast was mijn intentie zoals
> gezegd (op irc) eerdere correcties als die voor FF/TB ook apart op SM toe te
> passen en vanaf dan met dezelfde regelmaat mee te nemen, gevolgd door nalopen
> van de hele suite, waar nog behoorlijk wat aan scheelt.

patches voor SM2 graag in bug 369704 

> Uiteraard is de
> bijbedoeling om te 'backporten' naar 1.1.x indien mogelijk, en omgekeerd fouten
> in 1.1.x mee te nemen in 2.
> 
> Een toegevoegde SM-vraag: blijven wijzigingen voor 1.1.x alleen in bestandsvorm
> mogelijk, aangezien die niet in cvs staat? Zo ja dan wordt dat een drukke bug,
> tenzij aanleveren op een andere manier mogelijk is.
> 
ik zou willen voorstellen om je voornamelijk te concentreren op SM2 . SM 1.1.x is alleen via Mozillatranslator / tekst editting aan te passen en ik weet nog niet of ik daar nog veel tijd in ga steken.
Attached patch nsserrors.properties (obsolete) — — Splinter Review 

    
    

    
  
Comment on attachment 281029 [details] [diff] [review]
nsserrors.properties

toegepast

        Attachment #281029 -
        Attachment is obsolete: true

    
    

    
  


  
Enkele voorkomens van ‘lokatie’ → ‘locatie’

Terwijl ik naar alle voorkomens van ‘lokatie’ zocht kwam ik met name veel fouten in de Seamonkey-vertaling tegen. Ik heb een aantal correcties aangebracht, deze zitten ook in deze patch (naast de ‘lokatie’-wijzigingen), maar ik heb maar een paar bestanden bekeken.

Als iemand van de Seamonkey-vertalers dit leest: let er alsjeblieft op dat je samenstellingen aan elkaar schrijft. En locatie met een c :).

Trouwens, gebruikt Seamonkey geen ’-apostroffen?

    
    

    
  
(In reply to comment #164)

> Als iemand van de Seamonkey-vertalers dit leest: let er alsjeblieft op dat je
> samenstellingen aan elkaar schrijft. En locatie met een c :).
> 
> Trouwens, gebruikt Seamonkey geen ’-apostroffen?
> 

De seamonkey vertaling is voor een groot deel nog een rechtstreekse overzetting vanuit de mozilla suite vertaald door onze voorgangers. Toen waren er nog geheel andere opvattingen hoe het vertaald moest worden (zie de vele discussies van toen ;-) )



    
    

    
  
Comment on attachment 287404 [details] [diff] [review]
Lokatie → locatie + samenstellingen e.d.

toegepast op de trunk samen met nog een paar kleine verbeteringen in de suite (webstekken => websites, add-on beheerder => add-onbeheerder, Java versie => Javaversie). Dingen die ook in deze patch voorkwamen maar ook nog in andere bestanden stonden.

        Attachment #287404 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Crashreporter(-override).ini (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 298758 [details] [diff] [review]
Crashreporter(-override).ini

toegepast, bedankt voor de vertaling.

    
    

    
  


  
Een ‘tussenstand’ in het nalopen van alle wijzigingen voor FF- en TK-bestanden vanaf de vorige keer (08/2007).

    
    

    
  


  
Infinitieven in importeerwizard en een paar correcties n.a.v. att 280454. Wellicht dat die op extensions.dtd een hunk geven, maar die volgt toch nog.

    
    

    
  


  
Foutje..

        Attachment #299881 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 299876 [details] [diff] [review]
Correcties FF/toolkit t/m 27/01 (deel 1)

patch toegepast

        Attachment #299876 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 299884 [details] [diff] [review]
Enkele infinitieven en correcties v2

Toegepast

        Attachment #299884 -
        Attachment is obsolete: true

    
    

    
  


  
Vervolg van eergisteren, toegepast op actuele bestanden.

    
    

    
  
Comment on attachment 300545 [details] [diff] [review]
Correcties FF/toolkit t/m 27/01 (deel 2)

toegepast

        Attachment #300545 -
        Attachment is obsolete: true

    
    

    
  


  
Vervolg van gisteren.

    
    

    
  
Comment on attachment 300809 [details] [diff] [review]
Correcties FF/toolkit t/m 27/01 (deel 3)

toegepast

        Attachment #300809 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 300977 [details] [diff] [review]
Correcties FF/toolkit t/m 27/01 (deel 4)

toegepast

        Attachment #300977 -
        Attachment is obsolete: true

    
    

    
  


  
De laatste, t/m 30/1.

    
    

    
  
Comment on attachment 301092 [details] [diff] [review]
Correcties FF/toolkit t/m 27/01 (deel 5/5)

toegepast, behalve de aanpassing aan marktplaats. deze wordt gedaan wanneer de markplaats url wordt aangepast via bug 353328

        Attachment #301092 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 302294 [details] [diff] [review]
Verifiëren, infinitieven, keys e.a.

toegepast

        Attachment #302294 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 302537 [details] [diff] [review]
Ondertekend -> Geauthenticeerd (2x)

toegepast

        Attachment #302537 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #180)
> Created an attachment (id=301092) [details]
> Correcties FF/toolkit t/m 27/01 (deel 5/5)

-<!ENTITY appManager.title     "Applicatie details">
+<!ENTITY appManager.title     "Applicatiedetails">

Net als vlak eronder zou ik hier ‘Toepassingsdetails’ van maken. (2x)

Super werk, Ton.

    
    

    
  
(In reply to comment #178)
> Created an attachment (id=300977) [details]
> Correcties FF/toolkit t/m 27/01 (deel 4)

+certErrorTrust_CaInvalid=Het certificaat wordt niet vertrouwd omdat het werd uitgegeven door een ongeldig CA-certificaat.

Als ik het goed begrijp is een CA een Certification Authority.  Deze kan certificaten uitgeven.  Maar het is niet het certificaat dat uitgeeft, dus iets is hier in de vertaling misgelopen.
Hm, zo te zien is het in het Engels net zo.  Snapt iemand dit, of is het een bug?

+certErrorTrust_Issuer=Het certificaat wordt niet vertrouwd omdat het uitgeverscertificaat niet vertrouwd is.
Het laatste woord zou ik door ‘wordt’ vervangen.  Ik weet wel dat het een toestand is, maar dat klinkt m.i. gewoon beter.  Idem een stukje verderop in het bestand.

+<!ENTITY certmgr.pending.label                "Momenteel certificaat aan het verifiëren…">
‘Momenteel’ weg, lijkt me.

+<!ENTITY protectedAuth.msg "Authenticeer bij de token. Authenticatiemethode hangt af van het type van uw token.">
Noch Van Dale, noch het Groene Boekje schijnen ‘token’ te kennen, maar voor mij is het toch echt *het* token, hoor.  *Zucht*, weer eens een reden om een nl-BE versie te starten!

+addExceptionExpiredShort=Gedateerde informatie
Dit klinkt me wat ouderwets, kan niet gewoon ‘verouderd’?

authoriteit =? autoriteit!! (addExceptionUnverifiedLong)

+addExceptionCheckingLong=Poging tot identificeren van de website…
identificeren -> identificatie?

    
    

    
  


  
(In reply to comment #186)
Applicatie -> Toepassing, ook elders maar niet overal.

(In reply to comment #187)
> 
> +certErrorTrust_CaInvalid=Het certificaat wordt niet vertrouwd omdat het werd
> uitgegeven door een ongeldig CA-certificaat.
> 
> Hm, zo te zien is het in het Engels net zo.  Snapt iemand dit, of is het een
> bug?
Inderdaad een vreemde zin die mogelijk fout is vertaald. Maar eens navragen of een bug aanmaken..

> +certErrorTrust_Issuer= -> wordt
In patch. Ook elders, in voor FF belangrijke bestanden.

> +<!ENTITY certmgr.pending.label                "_Momenteel certificaat aan het
Aangepast (niet overal).

> +<!ENTITY protectedAuth.msg "Authenticeer bij de token. Authenticatiemethode
> hangt af van het type van uw token.">
> Noch Van Dale, noch het Groene Boekje schijnen ‘token’ te kennen, maar voor
> mij is het toch echt *het* token, hoor.

Het komt toch vaker voor als ‘de’, m.n. in betekenis van het apparaat en tevens bij MS. Taalkundig (en->nl) ook geen nl equivalent dus in principe mannelijk..

> +addExceptionExpiredShort=Gedateerde informatie
> Dit klinkt me wat ouderwets, kan niet gewoon ‘verouderd’?
Prima.

> authoriteit =? autoriteit!! (addExceptionUnverifiedLong)
Uiteraard..

> +addExceptionCheckingLong=Poging tot identificeren van de website…
> identificeren -> identificatie?
Eens. 'k Meen dit onderzocht te hebben maar heb blijkbaar de onjuiste vorm verwerkt. Het was zeker laat. :)

    
    

    
  
Volgens mij is het ook 'het token'.

    
    

    
  
(In reply to comment #188)
> Created an attachment (id=303646) [details]
> Aanpassingen n.a.v. comment 186,187
> 
> (In reply to comment #186)
> Applicatie -> Toepassing, ook elders maar niet overal.

Ééntje gemist: NSSInitProblemX

> > +<!ENTITY protectedAuth.msg "Authenticeer bij de token. Authenticatiemethode
> > hangt af van het type van uw token.">
> > Noch Van Dale, noch het Groene Boekje schijnen ‘token’ te kennen, maar voor
> > mij is het toch echt *het* token, hoor.
> 
> Het komt toch vaker voor als ‘de’, m.n. in betekenis van het apparaat en
> tevens bij MS. Taalkundig (en->nl) ook geen nl equivalent dus in principe
> mannelijk..

Zie http://www.onzetaal.nl/advies/weblog.php: ik voel dit aan als een gevalletje voor uitzondering 7, n.a.v. de gelijkenis met ‘het teken’ (het is er ook mee verwant, zie http://en.wiktionary.org/wiki/token), maar leg me er graag bij neer als dat niet aanvaard is.


    
    

    
  
(In reply to comment #176)
> Created an attachment (id=300809) [details]
> Correcties FF/toolkit t/m 27/01 (deel 3)

-offlineApps.available=Deze website (%S) biedt data aan om op te slaan op uw computer voor offline gebruik.
+offlineApps.available=Deze website (%S) biedt aan om gegevens op uw computer op te slaan voor offlinegebruik.

Dit betekent niet hetzelfde.  Ik geloof dat het tweede juist is, maar zou in dat geval ‘voorstellen’ i.p.v. ‘aanbieden’ gebruiken.

+identity.encrypted=Uw verbinding met deze website is versleuteld om afluisteren te voorkomen.
‘Om afluisteren te voorkomen, is uw verbinding met deze website versleuteld.’  Klinkt iets beter, IMHO.

+SEC_ERROR_OCSP_RESPONDER_CERT_INVALID=Geconfigureerde certificaat van OCSP-responder is ongeldig.
Dit moet denk ik zijn: ‘Certificaat van ingestelde OCSP-responder is ongeldig.’  Waarom niet ‘beantwoorder’?

    
    

    
  
(In reply to comment #190)
> > Applicatie -> Toepassing, ook elders maar niet overal.
> 
> Ééntje gemist: NSSInitProblemX

Nee, met opzet laten staan. ‘Applicatiegedrag’ is een gangbare term die duidelijk de voorkeur verdient boven ‘toepassingsgedrag’, vandaar.
  
> > Het komt toch vaker voor als ‘de’, m.n. in betekenis van het apparaat en
> > tevens bij MS. Taalkundig (en->nl) ook geen nl equivalent dus in principe
> > mannelijk..
> 
> Zie http://www.onzetaal.nl/advies/weblog.php: ik voel dit aan als een
> gevalletje voor uitzondering 7, n.a.v. de gelijkenis met ‘het teken’ (het
> is er ook mee verwant, zie http://en.wiktionary.org/wiki/token), maar leg me er
> graag bij neer als dat niet aanvaard is.

Uitzondering 7 zou de enige rechtvaardiging zijn, maar dan alleen als met token de (softwarematige) reeks cijfers werd bedoeld. Aangezien hier duidelijk wordt verwezen naar het apparaat (waarbij te identificeren) is dat dus niet van toepassing. Zie ook http://nl.wikipedia.org/wiki/Token_(identificatie).


    
    

    
  

      
      
      
      

        Attached patch
          
          
        Aanpassingen n.a.v. comment 191 (obsolete)
        — 
          — Splinter Review
      

    


  
(In reply to comment #191)
> -offlineApps.available=Deze website (%S) biedt data aan om op te slaan op uw
> computer voor offline gebruik.
> +offlineApps.available=Deze website (%S) biedt aan om gegevens op uw computer
> op te slaan voor offlinegebruik.
> 
> Dit betekent niet hetzelfde.  Ik geloof dat het tweede juist is, maar zou in
> dat geval ‘voorstellen’ i.p.v. ‘aanbieden’ gebruiken.

Betekenis was idd onjuist, voorstellen is niet gek. In patch.

> +identity.encrypted=Uw verbinding met deze website is versleuteld om
> afluisteren te voorkomen.
> ‘Om afluisteren te voorkomen, is uw verbinding met deze website
> versleuteld.’  Klinkt iets beter, IMHO.

Ook prima (zonder komma).

> +SEC_ERROR_OCSP_RESPONDER_CERT_INVALID=Geconfigureerde certificaat van
> OCSP-responder is ongeldig.
> Dit moet denk ik zijn: ‘Certificaat van ingestelde OCSP-responder is
> ongeldig.’  Waarom niet ‘beantwoorder’?

Volgorde aangepast, maar ik ben er niet voor om zo maar ‘geconfigureerde’ te vervangen door ‘ingestelde’, wat blijkbaar vaker is gebeurd.
Beantwoorder: dit wordt nergens gebruikt, aangezien OCSP-responder de gangbare term is.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Bijwerking->update (obsolete)
        — 
          — Splinter Review
      

    


  
Vervangt de termen met ‘bijwerking’ naar vergelijkbare met ‘update’ in het CRL-updatedeel. Dit uiteraard omdat de primaire betekenis van bijwerking een andere is, maar ook omdat we elders voor update als znw. gewoon update gebruiken. MS gebruikt overigens ook ‘update’ waar het CRL’s betreft.
Ook in de patch: r->W voor Weergaven in Places. Cosmetisch en kan hier geen kwaad.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Herroepen->Intrekken (obsolete)
        — 
          — Splinter Review
      

    


  
In een aantal gevallen is sprake van ‘herroepen’ c.q. ‘herroeping’. Dit is in de eerste plaats niet overal consistent, aangezien voor ‘revoke’ meestal al ‘intrekken’ wordt gebruikt. Daarnaast schijnen ‘certificaatintrekking’ en ‘intrekkingslijsten’ wat gangbaardere termen te zijn. Patch gemaakt op basis van hele trunk, dus ook mail.
Overigens viel me op dat eerder een dergelijke vraag over ‘revoke’ werd gesteld op Mozbrowser n.a.v. Enigmail.

    
    

    
  
(In reply to comment #174)
> Created an attachment (id=300545) [details]
> Correcties FF/toolkit t/m 27/01 (deel 2)

+feedSubscriptionFeed1=Dit is een "feed" met regelmatig veranderende inhoud op deze website. (en die eronder)
Gebruiken we voor dubbele aanhalingstekens nu wel of niet gekrulde?

+<!ENTITY noSearchResults.label            "Alle resultaten zijn al geïnstalleerd of niet compatibel.">
Ik vind ‘reeds’ hier beter klinken?

(In reply to comment #169)
> Created an attachment (id=299876) [details]
> Correcties FF/toolkit t/m 27/01 (deel 1)

+<!ENTITY search.scopeBarExpanderDown.tooltip       "Zoekbuilder tonen">
Hier moeten we toch een beter woord voor kunnen vinden.  Wat doet dit?

+detailsPane.oneItem=Een item
Moet dit niet Één item (dan wel Eén, zie http://taal.web-log.nl/taaladviesdienst/2008/01/k_en.html) zijn?

+offlineAppRemoveTitle=Offline websitegegevens verwijderen
+offlineAppRemovePrompt=%S zal niet meer offline beschikbaar zijn na het verwijderen van deze gegevens.  Weet u zeker dat u deze offlinewebsite wilt verwijderen?
+offlineAppRemoveConfirm=Offlinegegevens verwijderen
In de eerste ook maar aan elkaar?  Of misschien ‘Gegevens voor offlinewebsite verwijderen’?

+<!ENTITY cmd.showMac.label                "Tonen in Finder">
‘In Finder tonen’ bekt wat lekkerder, nee?  Dit is wel vaker: ik zie liever het werkwoord op het eind (Verwijderen van lijst -> Van lijst verwijderen)

+wpsDefaultOS2=WPS standaard
met streepje.

+# LOCALIZATION NOTE (mmMidiPlayerOS2): OS/2 only, default operation of MIDI files with OS/2 multimediaondersteuning geïnstalleerd
Hum, dat is natuurlijk niet de bedoeling.  Waarschijnlijk resultaat van een zoek-en-vervang?

(In reply to comment #167)
> Created an attachment (id=298758) [details]
> Crashreporter(-override).ini

+CrashReporterDefault=De crashreporter wordt uitgevoerd na een crash, om het probleem te rapporteren aan de maker van de toepassing.  Hij dient niet direct te worden gestart.
Het laatste is iets te vriendelijk.  ‘Het is niet de bedoeling hem direct te starten.’ of ‘Het is niet zinvol…’ of zelfs ‘Hij mag niet direct gestart worden’?

(In reply to comment #162)
> Created an attachment (id=281029) [details]
> nsserrors.properties

De token, heh :-p.  Niet grondig gecontroleerd, maar ziet er goed uit.


    
    

    
  
Comment on attachment 303646 [details] [diff] [review]
Aanpassingen n.a.v. comment 186,187

toegepast

        Attachment #303646 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 303820 [details] [diff] [review]
Aanpassingen n.a.v. comment 191

toegepast

        Attachment #303820 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 303837 [details] [diff] [review]
Bijwerking->update

toegepast

        Attachment #303837 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 303838 [details] [diff] [review]
Herroepen->Intrekken

toegepast (met de nodige hunks)

        Attachment #303838 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 303842 [details] [diff] [review]
Key voor ‘Nooit voor deze website’

toegepast, ton en hendrik weer bedankt voor jullie inzet

        Attachment #303842 -
        Attachment is obsolete: true

    
    

    
  


  
De patch spreekt voor zich denk ik!

    
    

    
  


  
(In reply to comment #197)
> 
> Gebruiken we voor dubbele aanhalingstekens nu wel of niet gekrulde?

Geen. Een goed punt echter, want aangezien ik er aanvankelijk nogal op tegen was ook dubbele curly’s te gebruiken denk ik inmiddels dat het geen kwaad kan (dan wel consequenter is) om dit nu ook maar eens te gaan doen. Leuk klusje. :)

> +<!ENTITY noSearchResults.label            "Alle resultaten zijn al
> geïnstalleerd of niet compatibel.">
> Ik vind ‘reeds’ hier beter klinken?

Ik ook, in patch.

> (In reply to comment #169)
> 
> +<!ENTITY search.scopeBarExpanderDown.tooltip       "Zoekbuilder tonen">
> Hier moeten we toch een beter woord voor kunnen vinden.  Wat doet dit?

Dit is het uitgebreide zoekgedeelte dat verschijnt in het bladwijzervenster (zie bug 387744). OpenOffice gebruikt voor builder iets als constructor, maar dat is dan in een andere context. Wellicht dat we het woord hier kunnen vermijden en gewoon ‘Zoekvelden tonen(/verbergen)’ kan worden, ondanks dat dit dezelfde term is als voor het veld erboven (->in patch). In het Frans doet men dit trouwens ook, in het Duits zien we ‘Suchwerkzeug’ (brr..). De optie lijkt trouwens omgekeerd te werken t.o.v. wat de bedoeling is. :-/

> +detailsPane.oneItem=Een item
> Moet dit niet Één item (dan wel Eén, zie
> http://taal.web-log.nl/taaladviesdienst/2008/01/k_en.html) zijn?

Moet niet maar mag wel, en is wellicht beter. Maar dan wel als ‘Eén’. Blijkbaar hoeft het niet in de patch..

> +offlineAppRemoveTitle=Offline websitegegevens verwijderen
> +offlineAppRemoveConfirm=Offlinegegevens verwijderen
> In de eerste ook maar aan elkaar?  Of misschien ‘Gegevens voor offlinewebsite
> verwijderen’?

Dit is al gewijzigd in deel 5 (aan elkaar).

> +<!ENTITY cmd.showMac.label                "Tonen in Finder">
> ‘In Finder tonen’ bekt wat lekkerder, nee?  Dit is wel vaker: ik zie liever
> het werkwoord op het eind (Verwijderen van lijst -> Van lijst verwijderen)

Over de voorkeur het werkwoord (=de actie) vooraan te schrijven hebben we het al eens gehad. Daarbij schijnt ‘Tonen in Finder’ een gebruikte term bij Mac te zijn, o.a. door Adobe.

> +wpsDefaultOS2=WPS standaard
> met streepje.

Liever zonder; ik beschouw dit als een woordgroep, net zoals dat bij ‘Google standaard’ gebeurt (met klemtoon op ‘stan’). Het is dus geen znw., zoals ‘de WPS-standaard’..

> +# LOCALIZATION NOTE (mmMidiPlayerOS2): OS/2 only, default operation of MIDI
> files with OS/2 multimediaondersteuning geïnstalleerd
> Hum, dat is natuurlijk niet de bedoeling.  Waarschijnlijk resultaat van een
> zoek-en-vervang?

Vreemd. Zoek-en-vervang gebruik ik doorgaans niet, maar ik denk dat ik hier abusievelijk commentaar heb gewijzigd en blijkbaar niet volledig heb hersteld. In patch.

> (In reply to comment #167)
> 
> +CrashReporterDefault=De crashreporter wordt uitgevoerd na een crash, om het
> probleem te rapporteren aan de maker van de toepassing.  Hij dient niet direct
> te worden gestart.
> Het laatste is iets te vriendelijk.  ‘Het is niet de bedoeling hem direct te
> starten.’ of ‘Het is niet zinvol…’ of zelfs ‘Hij mag niet direct
> gestart worden’?

‘Niet de bedoeling’ c.q. ‘niet zinvol’ sluit gebruik niet uit ("u kunt het wel doen, maar.."), en het laatste vind ik weer te streng (en is trouwens groene stijl ;) ). Vertalen van ‘should’ met ‘dient’ is v.z.i.w. ook vrij gebruikelijk. Vervangen van Hij door Deze lijkt me echter wel OK (in patch).

Ook: Anderen -> Overige (certificaten), gecontroleerd-> geverifieerd en nog wat kleinigheidjes n.a.v. laatste wijzigingen.

    
    

    
  
Comment on attachment 304248 [details] [diff] [review]
Een (…) download → Eén (…) download

toegepast

        Attachment #304248 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 304353 [details] [diff] [review]
Aanpassingen n.a.v. comment 197, e.a.

toegepast

        Attachment #304353 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #197)

> +detailsPane.oneItem=Een item
> Moet dit niet Één item (dan wel EEn, zie
> http://taal.web-log.nl/taaladviesdienst/2008/01/k_en.html) zijn?
> 

vervangen door "Eén item"

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties afgelopen dagen (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  

      
      
      
      

        Attached patch
          
          
        directory -> map (obsolete)
        — 
          — Splinter Review
      

    


  
Ik erger me er al een tijdje aan dat in de voorkeuren voor Thunderbird ‘Lokale directory’ staat.  Dit heeft niets met LDAP of wat dan ook te maken, het is gewoon een map.

    
    

    
  
(In reply to comment #209)
> Created an attachment (id=306367) [details]
> directory -> map

Ik kan me iets herinneren over een discussie hierover maar wil dat nog wel nakijken; het was zoiets als dat dit OS-specifiek zou zijn, met als conclusie dat gemengd gebruik van ‘map’ en ‘directory’ werd geaccepteerd (vandaar dat ‘directory’ ook meer voorkomt dan enkel op deze plaatsen). Overigens zou je een access key vergeten in een venster dat geen ruimte biedt voor andere keys..

    
    

    
  
(In reply to comment #203)
> Created an attachment (id=304248) [details]
> Een (…) download → Eén (…) download

Ik denk dat er spaties ontbreken na de ‘;’ ?

(In reply to comment #204)
> Created an attachment (id=304353) [details]
> Aanpassingen n.a.v. comment 197, e.a.

> Ook: Anderen -> Overige (certificaten)

Overige, of overigen?  Gaat het om personen?

(In reply to comment #210)
> Ik kan me iets herinneren over een discussie hierover maar wil dat nog wel
> nakijken; het was zoiets als dat dit OS-specifiek zou zijn, met als conclusie
> dat gemengd gebruik van ‘map’ en ‘directory’ werd geaccepteerd (vandaar
> dat ‘directory’ ook meer voorkomt dan enkel op deze plaatsen). 

Volgens mij had dat met LDAP te maken, wat hier dus niet het geval is.  Ik ben hierop gekomen door via de telefoon met mijn moeder problemen op te lossen, het is dus zowel op Windows als op Linux dir, zonder reden.

> Overigens
> zou je een access key vergeten in een venster dat geen ruimte biedt voor andere
> keys..

Ach ja, accesskeys… \me hits himself on the head.  Ik maak dit weekend een nieuwe patch waar die in verwerkt zijn.



    
    

    
  
(In reply to comment #211)
> 
> Ik denk dat er spaties ontbreken na de ‘;’ ?

Waarom? a) ook niet in Engels en b) niet nodig daar ze gescheiden worden weergegeven.

> (In reply to comment #204)
> 
> Overige, of overigen?  Gaat het om personen?

Wat denk je zelf? :)

> (In reply to comment #210)
> 
> Volgens mij had dat met LDAP te maken, wat hier dus niet het geval is.  Ik ben
> hierop gekomen door via de telefoon met mijn moeder problemen op te lossen, het
> is dus zowel op Windows als op Linux dir, zonder reden.

Ook (LDAP), maar tevens wordt folder consequent met map vertaald, en directory met opzet niet, mogelijk zelfs om OS-specifieke redenen. Het lijkt me niet de bedoeling enkele ervan zo maar te wijzigen om dat ze (jou) ergens niet bevallen. Als je denkt dat je een goed punt hebt het woord directory om een goede reden globaal te elimineren dan is dat iets anders, wat je in dat geval zou kunnen voorstellen via en-US, waarna nl kan volgen.

> Ach ja, accesskeys… \me hits himself on the head.  Ik maak dit weekend een
> nieuwe patch waar die in verwerkt zijn.

Ik zou de moeite besparen..


    
    

    
  

      
      
      
      

        Attached patch
          
          
        Key, ellipsis, typo’s (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 298758 [details] [diff] [review]
Crashreporter(-override).ini

al lang

        Attachment #298758 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #213)
> Created an attachment (id=306718) [details]
> Key, ellipsis, typo’s

-# LOCALIZATION NOTE: do not localize <handler command="...">
-CommandNotInChrome=Gebruik van <handler command="..."> niet toegestaan buiten de chrome.
+# LOCALIZATION NOTE: do not localize <handler command="…">
+CommandNotInChrome=Gebruik van <handler command="…"> niet toegestaan buiten de chrome.
Oh oh: dit mag niet!  (Het gebruik van ellipsis in die commando’s leidt ertoe dat ChatZilla en Venkman niet meer werken, ik weet niet of dit hier ook het geval is.)

    
    

    
  
(In reply to comment #215)

> Oh oh: dit mag niet!  (Het gebruik van ellipsis in die commando’s leidt ertoe
> dat ChatZilla en Venkman niet meer werken, ik weet niet of dit hier ook het
> geval is.)

Waarom staat dit dan nog steeds in en-US trunk, a.g.v. je eigen patch (attachment 290319 [details] [diff] [review] in bug 373623) en is dat niet teruggetrokken?



    
    

    
  
(In reply to comment #209)
> Created an attachment (id=306367) [details]
> directory -> map

Ok, na wat overleg/uitzoekerij (Vrijschrift/Wiki) is gebleken dat Map inmiddels wat geaccepteerder is dan voorheen, ondanks de cross-compatibiliteit. Hendrik is a.h.g.i. bezig e.e.a. na te lopen.

    
    

    
  


  
Zo, na uitvoerige discussie zijn we eruit gekomen dat:
- deze patch zinvol is
- de key er beter uit kan, daar er veel te veel van zijn en deze toch niks zinvols doet.
Ik heb dan maar meteen een paar ellipsisjes verbeterd in suite.

        Attachment #306367 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #216)
> (In reply to comment #215)
> 
> > Oh oh: dit mag niet!  (Het gebruik van ellipsis in die commando’s leidt ertoe
> > dat ChatZilla en Venkman niet meer werken, ik weet niet of dit hier ook het
> > geval is.)
> 
> Waarom staat dit dan nog steeds in en-US trunk, a.g.v. je eigen patch
> (attachment 290319 [details] [diff] [review] in bug 373623) en is dat niet teruggetrokken?

Wordt voor gezorgd.  Ik stel voor dat we commentaar in bug 373623 afwachten.  De rest van de patch kan wel.



    
    

    
  

      
      
      
      

        Attached patch
          
          
        Livebladwijzers (obsolete)
        — 
          — Splinter Review
      

    


  
De oplettende kijker heeft misschien al gezien dat het begrip ‘livetitel’ de intrede heeft gedaan, hetgeen aanvankelijk ook zo (als één woord) is ingebracht, op de meeste plaatsen althans. Mede hierom, maar eigenlijk al langer (het is meen ik al eens even ergens ter sprake gekomen) lijkt het me beter dit ook bij Livebladwijzers te doen. Taalkundig heeft deze vorm de voorkeur (à la liveprogramma, livewedstrijd, live-uitzending etc.), m.i. ook ter voorkoming van verwarring, en dan hebben we het nog niet eens over klemtonen. Neem als voorbeeld ‘Live bladwijzers toevoegen’: dit is interpreteerbaar als ‘live een aantal bladwijzers toevoegen’. Hiermee is meteen duidelijk dat ‘live’ (lees: levend / online) in het Nederlands zowel op het zelfstandig naamwoord als op het werkwoord kan slaan, en dit is natuurlijk onwenselijk. Ik begreep dat ook Hendrik zich in de wijziging kan vinden.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        directory -> map, nu overal (obsolete)
        — 
          — Splinter Review
      

    


  
Op instigatie van Ton heb ik overal gezocht en nog meer voorkomens gevonden van directory, die door map konden vervangen worden.
Daarbij ook de accesskeys gefixt, die ik voordien fout had gedaan.

        Attachment #306745 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #219)
> 
> Wordt voor gezorgd.  Ik stel voor dat we commentaar in bug 373623 afwachten. 
> De rest van de patch kan wel.

De patch kan helemaal, aangezien het hier geen code betreft maar een commentaar- en tekstregel _over_ code (zie de bug).

(In reply to comment #221)
> Created an attachment (id=306776) [details]
> directory -> map, nu overal

Beter, maar je vergat 1 geval van ‘back-up’. Hierin is echter nog een inconsistentie te vinden, daar dit in de vergelijkbare strings (zie dezelfde patch) ‘reservekopie’ is geworden, dus het lijkt me beter dit in de filter.*-bestanden ook te doen. Verder haal je in de suite-bestanden localPath.accesskey nog geheel weg i.p.v. "" te plaatsen. Als je e.e.a. dus even aan wilt passen..

    
    

    
  
Comment on attachment 306718 [details] [diff] [review]
Key, ellipsis, typo’s

toegepast

        Attachment #306718 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 306776 [details] [diff] [review]
directory -> map, nu overal

toegepast met lege acceskeys toegevoegd

        Attachment #306776 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #222)

> 
> Beter, maar je vergat 1 geval van ‘back-up’. Hierin is echter nog een
> inconsistentie te vinden, daar dit in de vergelijkbare strings (zie dezelfde
> patch) ‘reservekopie’ is geworden, dus het lijkt me beter dit in de
> filter.*-bestanden ook te doen. Verder haal je in de suite-bestanden
> localPath.accesskey nog geheel weg i.p.v. "" te plaatsen. Als je e.e.a. dus
> even aan wilt passen..
> 

ik heb backup / back-up vervangen voor reservekopie in de trunk


    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties TB/editor t/m 03/03 (obsolete)
        — 
          — Splinter Review
      

    


  
Wijzigingen voor TB vanaf 08/2007 nagelopen, met hier en daar iets extra’s dat voor verbetering vatbaar was.

    
    

    
  
(In reply to comment #226)
> Created an attachment (id=307128) [details]
> Correcties TB/editor t/m 03/03

+<!ENTITY select.label             "of selecteer het materiaaltype om te importeren:">
‘type materiaal’ klinkt hier wat natuurlijker

Deze patch leidde me ertoe de volgende bugs te rapporteren: bug 420852 en bug 420853.  De laatste kunnen we misschien zelf oplossen door even te brainstormen over die string:

Nieuwsgroepen tonen die bevatten:

Misschien ‘Nieuwsgroepen filteren volgens:’ of ‘… die het volgende bevatten:’ (zo is het in de Duitse suite, terwijl TB ‘Lijst filteren volgens’ heeft) of ‘… met in de naam:’

    
    

    
  
(In reply to comment #222)
> (In reply to comment #219)
> > 
> > Wordt voor gezorgd.  Ik stel voor dat we commentaar in bug 373623 afwachten. 
> > De rest van de patch kan wel.
> 
> De patch kan helemaal, aangezien het hier geen code betreft maar een
> commentaar- en tekstregel _over_ code (zie de bug).

Inderdaad, dit is nu ook bevestigd in bug 373623.

    
    

    
  


  
(In reply to comment #227)
> 
> ‘type materiaal’ klinkt hier wat natuurlijker

Het was me opgevallen en heb het andere om een bepaalde reden laten staan (ik vond ‘type materiaal’ meer naar stoffen verwijzen), maar mede door de string ervoor vind ik het wel ok. Aangepast; er waren ook nog enkele andere dingen mis in hetzelfde bestand.

> Nieuwsgroepen tonen die bevatten:
> 
> Misschien ‘Nieuwsgroepen filteren volgens:’ of ‘… die het volgende
> bevatten:’ (zo is het in de Duitse suite, terwijl TB ‘Lijst filteren
> volgens’ heeft) of ‘… met in de naam:’

Qua woordvolgorde een punt, bug 420852 heeft wellicht kans van slagen. Tot die tijd vind ik de huidige vorm wel ok; het ‘tonen’ is immers belangrijk en anders wordt de string onnodig lang.

        Attachment #307128 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties afgelopen dagen v2 (obsolete)
        — 
          — Splinter Review
      

    


  
N.a.v. wijzigingen (back-up) in places.properties, e.a.

        Attachment #305411 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #229)
> Created an attachment (id=307565) [details]
> Correcties TB/editor t/m 03/03 v2
> 
> (In reply to comment #227)
> > 
> > ‘type materiaal’ klinkt hier wat natuurlijker
> 
> Het was me opgevallen en heb het andere om een bepaalde reden laten staan (ik
> vond ‘type materiaal’ meer naar stoffen verwijzen), maar mede door de
> string ervoor vind ik het wel ok. Aangepast; er waren ook nog enkele andere
> dingen mis in hetzelfde bestand.

Ik heb net het betreffende venster nog eens bekeken (Extra->Importeren), het is inderdaad moeilijk om een overkoepelend begrip te vinden voor ‘Adresboeken; E-mail; Instellingen’.  Misschien ‘type gegevens’?

> > Nieuwsgroepen tonen die bevatten:
> > 
> > Misschien ‘Nieuwsgroepen filteren volgens:’ of ‘… die het volgende
> > bevatten:’ (zo is het in de Duitse suite, terwijl TB ‘Lijst filteren
> > volgens’ heeft) of ‘… met in de naam:’
> 
> Qua woordvolgorde een punt, bug 420852 heeft wellicht kans van slagen. Tot die
> tijd vind ik de huidige vorm wel ok; het ‘tonen’ is immers belangrijk en
> anders wordt de string onnodig lang.

Ik vind het niet ok.  Het is een kromme zin.  Dan liever mijn eerste voorstel: 
‘Nieuwsgroepen filteren volgens:’ 

    
    

    
  


  
(In reply to comment #231)
> (In reply to comment #229)

> Ik heb net het betreffende venster nog eens bekeken (Extra->Importeren), het is
> inderdaad moeilijk om een overkoepelend begrip te vinden voor ‘Adresboeken;
> E-mail; Instellingen’.  Misschien ‘type gegevens’?

Niet gek, aangepast.

> > > Nieuwsgroepen tonen die bevatten:
> 
> Ik vind het niet ok.  Het is een kromme zin.  Dan liever mijn eerste voorstel: 
> ‘Nieuwsgroepen filteren volgens:’ 

De zinsbouw is misschien niet perfect (vandaar ook je aangemaakte bug, die uiteraard 420853 is), maar er zijn ergere gevallen van vreemde constructies dan deze, zoals bv. het zoekfilter. Had jij daar trouwens niet ooit een bug voor aangemaakt?

Wat betreft je suggestie: deze valt af, omdat we eerstens geen nieuwsgroepen filteren (wel een lijst), en als dat al zou gebeuren dan is dat op een categorie, niet op een in te vullen veld. Aanvankelijk wilde ik er dan maar "... tonen die het volgende bevatten" van maken, maar dit wordt gewoon wat te lang (de account- en invoervelden worden hierdoor immers korter, hoewel bij 3.0 een minder groot probleem dan bij 2.0) en het komt m.i. wat omslachtig over. Omdat ook ‘bevatten’ nog wat onduidelijheid zou kunnen geven heb ik er nu het compacte "Nieuwsgroepen tonen met de tekst:" van gemaakt (=even lang als ‘..die bevatten’) en zou graag zien dat je hier ook vrede mee hebt.

Verder nog enkele dingetjes aangepast in dezelfde bestanden (keys, voorkeuren, nieuwsgroepen).

    
  

        Attachment #307565 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 307568 [details] [diff] [review]
Correcties afgelopen dagen v2

toegepast

    
  

        Attachment #307568 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 308217 [details] [diff] [review]
Correcties TB/editor t/m 03/03 v3

toegepast

        Attachment #308217 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 306752 [details] [diff] [review]
Livebladwijzers

toegepast

        Attachment #306752 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Help-bestanden t/m vandaag (obsolete)
        — 
          — Splinter Review
      

    


  
Werkt de bestanden bij t.o.v. de Engelse en verwijdert tevens de niet-unicodetekens als &euml; etc.

    
    

    
  
Comment on attachment 310247 [details] [diff] [review]
Help-bestanden t/m vandaag

toegepast

        Attachment #310247 -
        Attachment is obsolete: true

    
  
Depends on: 353154

    
    

    
  
(In reply to comment #236)
> Created an attachment (id=310247) [details]
> Help-bestanden t/m vandaag

+  <div class="contentsBox"><em>09 juli 2005</em></div>
Voor mij toch liever zonder 0.

-      <td><span class="noMac">Snelkoppeling kopi&euml;ren</span><span class="mac">
-        Snelkoppeling kopi&euml;ren</span></td>
-      <td>Koppelingslocatie kopi&euml;ren</td> 
+      <td><span class="noMac">Snelkoppeling kopi�ren</span><span class="mac">
+        Snelkoppeling kopi�ren</span></td>
+      <td>Koppelingslocatie kopi�ren</td> 
Oppassen hier.  De andere bestanden lijken wel in orde.  Is forieusers.xhtml niet in utf-8?  Zou wel moeten.  In MXR ziet het er goed uit.

-<p>Auteursrecht &copy; 2003-2006 Medewerkers van het Mozilla Help Viewer Project.</p>
+<p>Auteursrecht &copy; &copyright.years; Medewerkers van het Mozilla Help Viewer Project.</p>
Zeer goed dat ze dat eindelijk eens slim opgelost hebben.
Nu nog © i.p.v. &copy; :-)

-  <h3 id="add_to_bookmarks">Bladwijzer voor deze pagina maken…</h3>
+  <h3 id="add_to_bookmarks">Bladwijzer voor deze pagina maken</h3>
Hier haal je de puntjes weg, terwijl je ze elders behoudt.  En de puntjes zijn er ook in het menu-item, ik denk dus dat ze moeten blijven.

creditcardinformatie
wat is er mis met ‘kredietkaartinformatie’?

+      <li><a href="#applications_options">Toepassingen&pref.plural;</a></li>
Ik zou er ‘Toepassingsopties/-voorkeuren’ van maken. (met de &pref dan hé)

monospace-lettertypen
vastebreedtelettertypen?

<p>U kunt een lokale toepassing kiezen voor het behandelen van elk willekeurig type.
+  Voor het behandelen van sommige typen kunt u ook een webtoepassing kiezen, een functie
+  (zoals <a href="glossary.xhtml#live_bookmark">livebladwijzers</a> voor feeds)
+  of een <a href="glossary.xhtml#Plugin">plug-in</a> in &brandShortName; kiezen,
+  of het bestand opslaan op uw computer.</p>
Hier komt ‘kiezen’ eenmaal te veel of te weinig voor.

Moet nu ophouden, later de rest.

    
    

    
  
(In reply to comment #238)
> (In reply to comment #236)
> 

graag de discussie over de helpbestanden in bug 353154

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties FF/toolkit t/m 24/03 (obsolete)
        — 
          — Splinter Review
      

    


  
Inclusief enkele aanpassingen.

    
    

    
  
Comment on attachment 311498 [details] [diff] [review]
Correcties FF/toolkit t/m 24/03

toegepast

        Attachment #311498 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties FF/TK 01/04 e.a. (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 313007 [details] [diff] [review]
Correcties FF/TK 01/04 e.a.

toegepast

        Attachment #313007 -
        Attachment is obsolete: true

    
    

    
  


  
Op de vertalinglijst voor vrije software zijn we er onlangs opgekomen dat het de-installeren moet zijn.  Het GB kent het niet, maar wel de-escalatie, Van Dale heeft het ook.

Verder ook in suite alle puntjes vervangen door ellipsis (dit is ondertussen ook in en-US) en recht aanhalingstekens door gekrulde vervangen.  Hier is nog wat werk aan de winkel, dat volgt nog.

Er is iets mis met install.it in suite, daar ben ik afgebleven.

    
    

    
  
(In reply to comment #244)
> Verder ook in suite alle puntjes vervangen door ellipsis (dit is ondertussen
> ook in en-US) en recht aanhalingstekens door gekrulde vervangen.

-WarningOSTZNoMatch=Waarschuwing: tijdzone "%1$S" van besturingssysteem\nkomt niet meer overeen met ZoneInfo-tijdzone "%2$S".
+WarningOSTZNoMatch=Waarschuwing: tijdzone “%1$S” van besturingssysteem\nkomt niet meer overeen met ZoneInfo-tijdzone "%2$S".

Ik raad aan om de wijziging in dubbele gekrulde aanhalingstekens grondig te testen, want ik heb gemerkt dat dit problemen kan geven en misschien zelfs onmogelijk is.

    
    

    
  
Comment on attachment 313202 [details] [diff] [review]
deïnst -> de-inst, ellipsis in suite

Koen wil jij het calender gedeelte van deze patch bekijken en goedkeuren, daarna zal ik hem toepassen in de trunk.

        Attachment #313202 -
        Flags: review?(koen.hendrickx)

    
    

    
  
> (In reply to comment #244)
> > Verder ook in suite alle puntjes vervangen door ellipsis (dit is ondertussen
> > ook in en-US) en recht aanhalingstekens door gekrulde vervangen.
> (In reply to comment #245 (irc))
> > <Hendrik> bedoel je dat ik het eerst moet compileren en bouwen? Ja, daar heb je gelijk in, al geloof ik niet dat het een probleem zal zijn

Compileren hoeft niet (nooit eigenlijk), maar het minste wat je kan doen is testen of dergelijke typografische wijzigingen wel kunnen werken middels een lokaal aangepast bestand, en ik weet nog steeds niet zeker of je dit wel altijd doet. Die ‘curly double’ heb ik onlangs eens getest - weliswaar alleen met menuOpenLivemarkOrigin.label - en dat bleek toen niet te werken, vandaar mijn opmerking hierboven. Vandaag werkt deze echter wel dus er moet toen iets fout zijn gegaan, tenzij het een andere string is geweest en er dus wel degelijk gevallen zijn die niet werken (of het was erg laat :) ). Al met al lijkt het me mede n.a.v. advies van Axel vandaag op de vraag of dit zonder meer overal kan, verstandig hier voorzichtig mee om te gaan. Je hebt gezien dat een dergelijke wijziging bij de enkele ook wat problemen heeft gegeven, dus overal waar een dubbele quote voorkomt eerst testen i.p.v. even snel meenemen zoals hier of gewoon overal en zelfs aparte patches maken voor dtd en properties (m.u.v. de welbekende bestanden) is raadzaam, mede omwille van het overzicht, om ze later terug te kunnen trekken of om de (test)posities ervan te vinden. M.a.w., probeer alleen dat te posten waarvan je zeker weet dat het werkt (en uiteraard indien mogelijk, wat goed is).

Calendar-bestanden: afgezien van dat je de genoemde dubbele quote wel eenmaal vooraan in de string wilde wijzigen en niet achteraan, komen ze nog vaker voor. Belangrijker nog is dat je nu ook wijzigingen wilt aanbrengen in diverse bestanden die enkele weken geleden nog zijn hersteld met een geldige reden; alle mogelijke (!) ellips-wijzigingen zouden dus in orde moeten zijn. Ik meen dat het eerder is genoemd, maar zowel verdiepen in de historie van een bestand als het in gedachte houden / teruglezen van recente wijzigingen (zie de bugs of je mailbox) is wenselijk..

Als je in de Calendar-bestanden alleen ‘de-installeren’ wijzigt is de patch wel OK. Curly’s moeten maar eerst worden getest, misschien zelfs i.h.b. vanwege de 1_8_branch.

En als je toch bezig bent, kun je wellicht mooi de 2 door jou eerder genoemde ellipsen meenemen (organiseren...)? Sinds 2 dagen mogen ze weer. ;)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        3 keys en correcties t/m 06-04 (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 313996 [details] [diff] [review]
3 keys en correcties t/m 06-04

toegepast

        Attachment #313996 -
        Attachment is obsolete: true

    
  

        Attachment #313202 -
        Attachment is obsolete: true

        Attachment #313202 -
        Flags: review?(koen.hendrickx)

    
    

    
  
Comment on attachment 313202 [details] [diff] [review]
deïnst -> de-inst, ellipsis in suite

toegespast zonder het calendar gedeelte, graag die patch aanbieden in de calendar bug.

    
    

    
  
(In reply to comment #242)
> Created an attachment (id=313007) [details]
> Correcties FF/TK 01/04 e.a.

Heb je iets tegen ‘om’? ;-)
Ik vind de wijzigingen wel goed hoor, maar vraag me af waarom je die eruit wil.  Voor mij klinken ze met ‘om’ ook goed.

+blocklistRestartMsg2=U zou %S opnieuw moeten starten zodat deze add-ons kunnen worden uitgeschakeld.
Deze vind ik wat ongelukkig geformuleerd.  Het mag wat dwingender klinken, lijkt me.  Misschien ‘Het is aangeraden %S opnieuw te starten …’?

Het valt me op dat dit soort zinnetjes vaak op heel verschillende manieren wordt geformuleerd, maar dat is doordat we dicht bij het Engelse origineel proberen aan te leunen.  Het is natuurlijk onbegonnen werk te proberen dat wat consistenter te maken (in en-US, maar ook in nl), maar ik vind het wel jammer.

    
    

    
  


  
A part of attachment 313202 [details] [diff] [review] was rejected when i applied it and i noticed it today please approve this patch for RC1

        Attachment #315532 -
        Flags: review?(l10n)

    
    

    
  
Comment on attachment 315532 [details] [diff] [review]
rejected part of attachment 313202 [details] [diff] [review] 

a=me, for future reference, please file independent bugs for things you want to land, otherwise it's not really possible to track down what did and what did not get landed.

Please land with a check-in comment referencing this bug and my approval.

        Attachment #315532 -
        Flags: review?(l10n) → approval1.9+

    
    

    
  
Comment on attachment 315532 [details] [diff] [review]
rejected part of attachment 313202 [details] [diff] [review] 

toegepast

        Attachment #315532 -
        Attachment is obsolete: true

    
    

    
  
Can this bug be closed?

    
    

    
  
As there are no objections, I'm closing this bug. That way, I get it off the bugzilla query for non-fixed bugs with approved patches.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED

    
    

    
  
no objections
Status: RESOLVED → VERIFIED

    
    

    
  
En waar hangen we nu nieuwe patches?  Ik heb dan maar een nieuwe bug gemaakt: bug 433976, maar ik heb nog een opvolgingspatch, van foutjes die me opgevallen zijn tijdens het proces.  Zal ik die maar hier hangen?  De andere moet sowieso eerst, anders zullen ze conflicteren.

    
    

    
  
Het werk aan firefox 3.1 gaat door in  Bug 453297

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: