Closed Bug 357099 Opened 18 years ago Closed 13 years ago

Dutch (nl) translation of calendar to v1.0

Categories

(Mozilla Localizations :: nl / Dutch, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: koen.hendrickx, Assigned: Tonnes)

References

Details

Attachments

(52 obsolete files) 

Na de release van v0.3 kunnen we verder vertalen naar de 0.5 release toe.
Wijzigingen in Engelse bestanden toegevoegd aan trunk en branch_1_8
"chrome/calendar/calendar.dtd" 
"chrome/calendar/calendar.properties" 
"chrome/calendar/preferences/connection.dtd" 
"chrome/calendar/wcap.properties" 
"chrome/lightning/lightning.dtd"

Bestand toegevoegd aan trunk en branch_1_8
"chrome/calendar/preferences/advanced.dtd"
Attached patch Correcties 30/10 (obsolete) — — Splinter Review 

    
    

    
  
Comment on attachment 244162 [details] [diff] [review]
Correcties 30/10

Patch ingechecked in trunk en 1_8_branch

        Attachment #244162 -
        Attachment is obsolete: true

    
    

    
  
'calendar' wordt momenteel consequent vertaald als 'kalender'. 
Er zijn op het forum van Mozbrowser enige tijd geleden stemmen opgegaan om dit te vertalen door 'agenda'.
http://www.mozbrowser.nl/forum/viewtopic.php?t=8209&highlight=kalender+agenda 

[quote] Nirwana op 06/09/2006:
Algemeen: als je "calendar" met "agenda" zou vertalen dan denk ik dat het veel meer mensen duidelijk maakt waar het voor dient. Een kalender is wat mij betreft iets wat aan de muur hangt (altijd handig voor verjaardagen) en een agenda is iets waarin je je afspraken beheert. Volgens mij doe je met Sunbird uiteindelijk vooral dat laatste. [/quote]



    
    

    
  
Volgens die redenering zou ‘Calendar’ in het Engels ook beter ‘Schedule’ kunnen heten... niet?

Mij lijkt het beter om de directe vertaling van Calendar (dwz. Kalender) aan te houden.

~Grauw

    
    

    
  
(In reply to comment #4)
> 'calendar' wordt momenteel consequent vertaald als 'kalender'. 
> Er zijn op het forum van Mozbrowser enige tijd geleden stemmen opgegaan om dit
> te vertalen door 'agenda'.

Ik ben hier ook wel voor.  In het Engels (en ook het Duits overigens) wordt er geen verschil gemaakt tussen wat bij ons kalender en agenda is.  Agenda in het Engels wordt alleen in de vergaderbetekenis gebruikt.

Schedule is nog weer wat anders: een planning of schema, maar niet het boekje/programma waar je die planning in noteert!

    
    

    
  
(In reply to comment #4)
> 'calendar' wordt momenteel consequent vertaald als 'kalender'. 
> Er zijn op het forum van Mozbrowser enige tijd geleden stemmen opgegaan om dit
> te vertalen door 'agenda'.
> http://www.mozbrowser.nl/forum/viewtopic.php?t=8209&highlight=kalender+agenda 
> 
> [quote] Nirwana op 06/09/2006:
> Algemeen: als je "calendar" met "agenda" zou vertalen dan denk ik dat het veel
> meer mensen duidelijk maakt waar het voor dient. Een kalender is wat mij
> betreft iets wat aan de muur hangt (altijd handig voor verjaardagen) en een
> agenda is iets waarin je je afspraken beheert. Volgens mij doe je met Sunbird
> uiteindelijk vooral dat laatste. [/quote]
> 

Ik ben er absoluut op tegen! Namen van programma's vertalen we niet (met de c/k verandering kan ik nog leven). 

    
    

    
  
(In reply to comment #7)
> 
> Ik ben er absoluut op tegen! Namen van programma's vertalen we niet (met de c/k
> verandering kan ik nog leven). 
> 

even iets nuanceren: Als er niet het programma mee bedoelt wordt kan het natuurlijk wel.

    
    

    
  
(In reply to comment #7)
> Ik ben er absoluut op tegen! Namen van programma's vertalen we niet (met de c/k
> verandering kan ik nog leven). 

Het is, hoe ik het zie, ook niet de bedoeling de naam van Calendar te veranderen, maar op de plaatsen in het programma waar naar een kalender/agenda verwezen wordt. 
-> naam programma: Calendar/Sunbird/Lightning
-> agenda's/kalenders waarin activiteiten worden genoteerd -> ???

Mijn overtuiging gaat meer naar agenda dan naar kalender. Gewoon omdat het voor mij natuurlijker aanvoelt. (Ik plan iets in mijn agenda.)
Wanneer ik daarentegen in mijn gsm (een Sony-Ericsson) ga kijken, noemt het zichzelf ook kalender... (met het oog op latere synchronisatie)



    
    

    
  
Wijzigingen in Engelse bestanden toegepast (en toegevoegd) aan trunk & branch_1_8

/chrome/calendar/dateFormat.properties
/chrome/prototypes/sun-calendar-event-dialog.dtd
/chrome/prototypes/sun-calendar-event-dialog.properties

Sorry voor de vergeten commentaar bij de trunk.

    
    

    
  
Wijzigingen in Engelse bestanden toegepast (en toegevoegd) op branch en trunk.

chrome/calendar/migration.dtd
chrome/calendar/migration.properties
chrome/prototypes/sun-calendar-event-dialog.properties

    
    

    
  
Files opnieuw toegevoegd voor probleem met line-endings
/chrome/prototypes/sun-calendar-event-dialog.dtd
/chrome/prototypes/sun-calendar-event-dialog.properties

    
    

    
  
Aanpassen in branch en trunk naar aanleiding van de compare.locales

/chrome/calendar/calendar.dtd
/chrome/calendar/menuOverlay.dtd
/chrome/calendar/preferences/advanced.dtd

    
    

    
  
aanpassingen in branch en trunk naar aanleiding van compare.locales.nl

/chrome/calendar/calendar-event-dialog.dtd
/chrome/calendar/calendar-recurrence-dialog.dtd
/chrome/calendar/calendar.dtd
/chrome/calendar/preferences/advanced.dtd
/chrome/prototypes/sun-calendar-event-dialog.dtd
/updater/updater.ini
Status: NEW → ASSIGNED

    
    

    
  
aanpassingen in branch en trunk naar aanleiding van compare.locales.nl

/chrome/calendar/calendar.properties
/chrome/prototypes/sun-calendar-event-dialog.dtd
/chrome/prototypes/sun-calendar-event-dialog.properties

    
    

    
  
/chrome/calendar/calendar-event-dialog.dtd
aangepast in branch en trunk.

Er was een probleem bij de build van het nighly language pack.
Ik heb "é" vervangen door "e", waarmee het probleem opgelost was. Ik dacht dat ik de code voor dit teken gebruikt had, maar blijkbaar is er toch iets verkeerds gelopen. 

Bestaat er ergens een lijst van die speciale tekens?

    
    

    
  
Bedoel je zoiets: http://www.lookuptables.com/

Even over Kalender of Agenda:
Calendar als project en als developversie van Sunbird hoeft natuurlijk
niet vertaald te worden (Zelfs niet als Kalender naar mijn mening). De
calendar add-on voor firefox is dood volgens mij en bij Thunderbird
vervangen door Lightning.
De Van Dale geeft:

*ag_e_n·da* (de ~, ~'s)
    *1* notitieboek waarin per dag de bezigheden, het huiswerk e.d.
    genoteerd kunnen worden
    *2* lijst van tijdens een vergadering te bespreken onderwerpen

*ka·l_e_n·der* (de ~ (m.), ~s)
    *1* lijst met de verdeling van het jaar in maanden, weken, dagen
    *2* lijst van kerkelijke feesten en heiligen => /calendarium,
    directorium, heiligenkalender/
    *3* tijdrekening

Naar deze definities gekeken zal de vertaling agenda moeten zijn.

    
    

    
  
(In reply to comment #16)
> /chrome/calendar/calendar-event-dialog.dtd
> aangepast in branch en trunk.
> 
> Er was een probleem bij de build van het nighly language pack.
> Ik heb "é" vervangen door "e", waarmee het probleem opgelost was. Ik dacht dat
> ik de code voor dit teken gebruikt had, maar blijkbaar is er toch iets
> verkeerds gelopen. 
> 
> Bestaat er ergens een lijst van die speciale tekens?

dtd-bestanden zijn utf-8 gecodeerd, je kan dus in principe gewoon é gebruiken.  Het is helemaal niet nodig een html-code te gebruiken.

Als je van een teken niet weet hoe je het moet ingeven, kan je het in de Unicode-charts opzoeken, en het dan als &#<nummer>; ingeven.  De fout die je dus maakte was die x: die hoort er niet, het nummer is al in hexadecimaal.  Overigens bestaan er voor alle tekens die in het Nederlands voorkomen ook named entities, voor é is dat dus &eacute; zoals je op de site die Foppe vermeld nalezen kan.

Maak er dus ajb snel weer privé, dan wel priv&eacute;, dan wel priv&#e9; van (hoofdletters of kleine maken niet uit voor de hexadecimale cijfers boven 9).



    
    

    
  
Um, codes met &#..; moeten decimaal zijn, zoals &#233;.

Als je een hexadecimale code wilt gebruiken moet je &#x..; schrijven, bijv. &#xE9;

Zie: http://www.w3.org/TR/html4/charset.html#h-5.3.1


~Grauw

    
    

    
  
(In reply to comment #19)
> Um, codes met &#..; moeten decimaal zijn, zoals &#233;.
> 
> Als je een hexadecimale code wilt gebruiken moet je &#x..; schrijven, bijv.
> &#xE9;
> 
> Zie: http://www.w3.org/TR/html4/charset.html#h-5.3.1

Grr, en ik daar maar naar zoeken en dan de verstrooide informatie verkeerd interpreteren.  

Nu zie ik ook wat het probleem is: Koen, je bent gewoon de ; op het einde vergeten!  Maar ik zie toch liever een echte é hoor.

    
    

    
  
Mee eens, Unicode ftw :). Het is leesbaarder en natuurlijker.

    
    

    
  
aanpassingen & toevoegingen in branch en trunk naar aanleiding van compare.locales.nl
Typfoutje rechtgezet

/chrome/calendar/calendar-event-dialog.dtd
/chrome/lightning/lightning.dtd
/chrome/prototypes/calendar-invitations-dialog.dtd
/chrome/prototypes/sun-lightning.dtd

    
    

    
  
Wijzigingen in Engelse bestanden toegevoegd aan trunk en branch_1_8

"chrome/calendar/calendar.dtd" (bug 215971)
"chrome/calendar/calendar.properties" (bug 362876)
"chrome/calendar/preferences/general.dtd" (bug 215971)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Mijn verbeteringen (obsolete)
        — 
          — Splinter Review
      

    


  
Ik ben eens over de hele Calendar-map gelopen, en dit zijn mijn verbeteringen.  Het één en ander zal wel weer door Ton afgeschoten worden, maar ik hoop dat toch het meeste doorgevoerd zal worden.

- html-entiteiten vervangen door UTF-8 (ook ... door … (2026 in unicode) en ‘ - ’ door ‘ – ’)
- kalender -> agenda dan wel Calendar, zoals gepast, ook volgens de discussie van voorheen
- geprobeerd het woord meerderewekenoverzicht te vermijden (zou, strikt genomen, zonder streepje moeten), ben echter niet zeker of dat geen plaatsproblemen oplevert
- ‘uw’ door ‘de’ vervangen waar dit kan, bekt beter m.i.
- ‘translaties’ een beetje weggewerkt
- AM/PM weg
- ook een paar foutjes

    
    

    
  
Hendrik: ziet er goed uit! Ben het eens met de wijzigingen, +1 van mij!

Eén wijziging snap ik niet helemaal:

- <!ENTITY newtodo.percentcomplete.label "&#37; voltooid">
+ <!ENTITY newtodo.percentcomplete.label "&percnt; voltooid">

En verder vind ik dit niet zo’n mooie zin, ik moet hem twee keer lezen:

+ <!ENTITY custompage.longdescription   "U kunt uw agenda een eigen naam geven, alsook een eigen kleur aan de gebeurtenissen van deze agenda" >

Maar dat kan in een latere patch ook nog wel aangepast worden.


~Grauw

    
    

    
  
(In reply to comment #25)
> Hendrik: ziet er goed uit! Ben het eens met de wijzigingen, +1 van mij!

:-)

> Eén wijziging snap ik niet helemaal:
> 
> - <!ENTITY newtodo.percentcomplete.label "&#37; voltooid">
> + <!ENTITY newtodo.percentcomplete.label "&percnt; voltooid">

&#37; en &percnt; zijn allebei codes voor het teken ‘%’, dat je in die bestanden niet rechtstreeks mag ingeven (denk ik).  Daarbij is &percnt; wel duidelijker: je kan gewoon lezen wat het is.  Dat vond ik gewoon duidelijker.

> En verder vind ik dit niet zo’n mooie zin, ik moet hem twee keer lezen:
> 
> + <!ENTITY custompage.longdescription   "U kunt uw agenda een eigen naam geven,
> alsook een eigen kleur aan de gebeurtenissen van deze agenda" >
> 
> Maar dat kan in een latere patch ook nog wel aangepast worden.

Ja, iets als ‘U kunt uw agenda een eigen naam geven, en de gebeurtenissen in deze agenda een eigen kleur geven’.

    
    

    
  
Comment on attachment 252367 [details] [diff] [review]
Mijn verbeteringen

Patch toegepast op trunk.
Problemen bij het patchen van bestanden:
- calendar.dtd
- lightning.dtd
Delen van deze wijzigingen sloegen ook op bestanden:
- calendar-event-dialog.dtd
- calendar-recurrence-dialog.dtd

        Attachment #252367 -
        Attachment is obsolete: true

    
    

    
  
Verdere aanpassingen voor kalender -> agenda in trunk.
- calendar/preferences/advanced.dtd
- calendar/preferences/general.dtd
- prototypes/sun-calendar-event-dialog.dtd
- prototypes/sun-calendar-event-dialog.properties
Als deze goed worden bevonden pas trek ik donderdagnamiddag de branch gelijk met de trunk.

Gisteren heb ik vernomen dat  
MOZILLA_1_8_BRANCH zal gebruikt worden voor versie 0.5
TRUNK zal verder gebruikt worden voor versie 0.7

    
    

    
  
MOZILLA_1_8_BRANCH is gelijkgezet met de TRUNK.

    
    

    
  
Aanpassingen in 1_8_BRANCH en TRUNK:
- chrome/calendar/calendar.properties
- chrome/calendar/wcap.properties
- chrome/calendar/preferences/timezones.dtd

Aanpassingen enkel in TRUNK
- chrome/calendar/preferences/connection.dtd

    
    

    
  
de builds in de de 1.8 branch worden nu ook getoold op de tinderbox pagina http://tinderbox.mozilla.org/showbuilds.cgi?tree=Mozilla1.8-l10n-nl

    
    

    
  

      
      
      
      

        Attached patch
          
          
        conflicten opgelost (obsolete)
        — 
          — Splinter Review
      

    


  
Dit zijn de dingen die er bij mij nog inzitten nadat ik de conflicten heb opgelost...

    
    

    
  
Comment on attachment 256668 [details] [diff] [review]
conflicten opgelost

Patch toegepast op 1_8_branch en trunk.

        Attachment #256668 -
        Attachment is obsolete: true

    
    

    
  
Aanpassing volgens gewijzigde Engelse file:
chrome/calendar/dateFormat.properties

    
    

    
  
Aanpassingen naar aanleiding van problemen bij Tinberbox-builds.

chrome/calendar/calendar.properties (Trunk en 1.8_branch)
installer/custom.properties (1.8_branch)

    
    

    
  
Dit zijn de laatste wijzigingen voor de 0.5 release. Wanneer er nog patchen worden gepost, gelieve deze te posten ten laatste op 28/03. De string freeze ligt op 30/03 en ik zou deze dus nog kunnen verwerken op 29/03. Alvast bedankt. grz.

Toevoegingen op 1.8_branch en trunk:
chrome/calendar/providers/gdata/gdata.properties
chrome/calendar/providers/gdata/gdata.dtd

Wijzigingen op 1.8_branch en trunk:
chrome/calendar/calendar.dtd
chrome/calendar/calendar.properties
chrome/lightning/lightning.properties
chrome/lightning/lightning.dtd
chrome/calendar/preferences/general.dtd
chrome/calendar/preferences/views.dtd

Wissen in 1.8_branch:
chrome/calendar/email.properties

    
    

    
  
De compare-locale heeft nog een foutje aan het licht gebracht... Bij deze is dit dus (hopelijk) rechtgezet... grz

Wijzigingen op 1.8_branch en trunk:
chrome/calendar/calendar.properties

Wissen in trunk:
chrome/calendar/email.properties

    
    

    
  
Wijzigingen op 1.8_branch en trunk: (bug 362698)
chrome/calendar/calendar.properties

    
    

    
  


  

    
    

    
  
(In reply to comment #39)
> Created an attachment (id=259819) [details]
> Correcties en wijzigingen t/m 27/03

Ziet er over het algemeen zeer goed uit.  Pft, dat ik over die formuleringen niet gestruikeld ben.  Zeer aandachtig heb ik het dan toch niet gelezen.  Een paar kleine opmerkingen:

-> Soms wordt ..., soms … gebruikt, ik zou het op prijs stellen als dit consequent het laatste zou kunnen worden.
-> Ik heb zo het gevoel dat er nog op andere plaatsen ook een paar maal ‘Gehele dag’ voorkomt, maar dat in deze patch niet verandert wordt.  ‘Hele dag’ is idd. beter.
-> Is het nu Sunbird of Calendar?
-> ‘Bezig met’ zie ik liever ‘aan het’ worden, maar die discussie was nog niet helemaal ten einde gevoerd.
  -> "Bezig met bijwerken van uitnodigingenlijst."> zou ik "Uitnodigingenlijst bijwerken." van maken
-> Spellingcontrole/spellingscontrole: tsja, voor mij eerder het tweede, maar het Groene Boekje schijnt ook een voorliefde voor samenstellingen met spelling in het eerste lid zonder s te hebben.
-> Klein foutje: spatie weg hier:
-<!ENTITY event.freebusy.next.slot        "Volgende vrije plaats" >
-<!ENTITY event.freebusy.previous.slot    "Vorige vrije plaats" >
+<!ENTITY event.freebusy.next.slot        "Volgende vrije plaats " >
+<!ENTITY event.freebusy.previous.slot    " Vorige vrije plaats" >
of niet?
->  ben je hier zeker van de volgorde van argumenten 1 en 2?  Als het volgens het Amerikaanse systeem is, dan moeten we die omdraaien, geloof ik:
-repeatDetailsRuleYearly4=the %1$S %2$S of %3$S
-repeatDetailsRuleYearly5=elke twee jaar de %1$S %2$S van %3$S
-repeatDetailsRuleYearly6=elke %4$S jaar de %1$S %2$S van %3$S
-repeatDetailsCount=Vindt plaats %1$S\niedere %2$S voor %3$S keer\n van %4$S tot %5$S.
+repeatDetailsRuleYearly4=de %1$S %2$S van %3$S
+repeatDetailsRuleYearly5=elke twee jaar op de %1$S %2$S van %3$S
+repeatDetailsRuleYearly6=elke %4$S jaar op de %1$S %2$S van %3$S
-> Hier moet waarschijnlijk iets als &brandShortName; in (bug melden bij en-US), en Softwareupdate.
 [Strings]
 Title=Software Update
-Info=Sunbird installeert uw updates en zal binnen enkele ogenblikken starten...
+Info=Sunbird installeert de updates en zal over enkele ogenblikken starten...


    
    

    
  


  
(In reply to comment #40)
> 
E.e.a. via irc doorgenomen en dit is de uitkomst.

> -> Soms wordt ..., soms … gebruikt, ik zou het op prijs stellen als dit
> consequent het laatste zou kunnen worden.
Ok, aangepast, behalve voor updater.ini.

> -> Ik heb zo het gevoel dat er nog op andere plaatsen ook een paar maal
> ‘Gehele dag’ voorkomt, maar dat in deze patch niet verandert wordt. 
Klopt, overige ook aangepast.

> -> Is het nu Sunbird of Calendar?
Koen: --> de nightlies zijn calendar, de officiele versies Sunbird

> -> ‘Bezig met’ zie ik liever ‘aan het’ worden, maar die discussie was
> nog niet helemaal ten einde gevoerd.
Liever niet als het met 'Aan het' begint, wel bv. '..de updates aan het installeren.'

>   -> "Bezig met bijwerken van uitnodigingenlijst."> zou ik "Uitnodigingenlijst
> bijwerken." van maken
Aangepast.

> -> Spellingcontrole/spellingscontrole: tsja, voor mij eerder het tweede, maar
> het Groene Boekje schijnt ook een voorliefde voor samenstellingen met spelling
> in het eerste lid zonder s te hebben.
Yep, dan ook maar overal.

> -> Klein foutje: spatie weg hier:
> -<!ENTITY event.freebusy.next.slot        "Volgende vrije plaats" >
> -<!ENTITY event.freebusy.previous.slot    "Vorige vrije plaats" >
> +<!ENTITY event.freebusy.next.slot        "Volgende vrije plaats " >
> +<!ENTITY event.freebusy.previous.slot    " Vorige vrije plaats" >
> of niet?
Bleek bij navraag toch nodig.

> ->  ben je hier zeker van de volgorde van argumenten 1 en 2?  Als het volgens
> het Amerikaanse systeem is, dan moeten we die omdraaien, geloof ik:
> -repeatDetailsRuleYearly4=the %1$S %2$S of %3$S
> -repeatDetailsRuleYearly5=elke twee jaar de %1$S %2$S van %3$S
> -repeatDetailsRuleYearly6=elke %4$S jaar de %1$S %2$S van %3$S
> -repeatDetailsCount=Vindt plaats %1$S\niedere %2$S voor %3$S keer\n van %4$S
> tot %5$S.
> +repeatDetailsRuleYearly4=de %1$S %2$S van %3$S
> +repeatDetailsRuleYearly5=elke twee jaar op de %1$S %2$S van %3$S
> +repeatDetailsRuleYearly6=elke %4$S jaar op de %1$S %2$S van %3$S
Volgorde OK maar wel repeatDetailsCount e.a. aangepast. Ook na navraag blijft er een beetje onduidelijkheid over %1$S maar wellicht in orde.

> -> Hier moet waarschijnlijk iets als &brandShortName; in (bug melden bij
> en-US), en Softwareupdate.
>  [Strings]
>  Title=Software Update
Het eerste is (nog) hardcoded in TB/FF/SB. Het laatste is goed gezien, maar dan wel met koppelteken.

Ook nog een key aangepast en Sluiten -> Afsluiten terug.

        Attachment #259819 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 259940 [details] [diff] [review]
Correcties en wijzigingen t/m 28/03 (v2)

Patch ingechecked in trunk en 1_8_branch

        Attachment #259940 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Key fixes and others (obsolete)
        — 
          — Splinter Review
      

    


  
De timing is misschien niet best, maar ik heb eens kritisch naar de conflicterende/niet-werkende keys gekeken in Lightning (niet SB) en daarnaast nog enkele kleine dingetjes aangepast, te weten 'Ga' eruit (mooier en korter in werkbalk), Gehele->Hele en Tentatief->Voorlopig.
Doordat er in TB's instellingenvenster voor Lightning maar liefst 28 unieke keys nodig zijn (a.g.v. bug 143065) en er van de 26 maar zo'n 22 bruikbaar zijn is het volgende eruit gerold. De gedachte was om de dubbele keys in de buttons te houden (T/B/V) zodat op zijn minst alle aanvinkbare items wel werken. Logischerwijs rees dan ook het idee om die button keys dan maar weg te halen als ze het toch niet doen, vandaar een bijna gelijke patch hierna die dat meeneemt. Als het aan mij ligt is de laatste oplossing de betere, ter voorkoming van klachten over niet-werkende keys, die overigens toch nog niet eerder hebben gewerkt dus het zou niet eens opvallen. :) Als dit nog in 0.5 meekan is het mooi, anders helaas..

Noot: de aanpassing &percnt; -> &#37; (zie bug 376000) zit hier uiteraard niet in ter voorkoming van problemen. Vraag aan Hendrik nog: wat te denken van overal ‘meerwekenoverzicht’ i.p.v. nu ook ‘overzicht meerdere weken’, of was daarvoor een reden?

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Key fixes and others v2 - no tbv (obsolete)
        — 
          — Splinter Review
      

    


  
Zie comment 43.

    
    

    
  


  
(In reply to comment #44)
> Key fixes and others v2 - no tbv
Was wat vergeten, net iets mooier.

        Attachment #260297 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #43)
> Created an attachment (id=260296) [details]
> Key fixes and others
> Gehele->Hele en Tentatief->Voorlopig.

Goed.

> Noot: de aanpassing &percnt; -> &#37; (zie bug 376000) zit hier uiteraard niet
> in ter voorkoming van problemen.

Oeps, mijn fout, maar vreemd, dat.

> Vraag aan Hendrik nog: wat te denken van
> overal ‘meerwekenoverzicht’ i.p.v. nu ook ‘overzicht meerdere weken’,
> of was daarvoor een reden?

Ik vond ‘meerderewekenoverzicht’ nogal omslachtig, maar zonder ‘dere’ is het wel ok.



    
    

    
  
Comment on attachment 260301 [details] [diff] [review]
Key fixes and others v2-2 - no tbv

Na permissie van Lilmatt:
Patch toegepast op 1_8_branch en trunk

        Attachment #260301 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 260296 [details] [diff] [review]
Key fixes and others

Nieuwere versie van deze patch ingelezen. Deze obsolete gezet...

        Attachment #260296 -
        Attachment is obsolete: true

    
    

    
  
koen vergeet je bug 376000 niet?

    
    

    
  
/chrome/calendar/preferences/timezones.dtd ingelezen in trunk en 1.8branch als gevolg van Engelse check in.

Off topic: Hoe kan ik me inschrijven dat ik ook op de hoogte wordt gebracht als er nieuwe bugs over de nederlandse vertaling ingechecked worden?

    
    

    
  
(In reply to comment #50)
> /chrome/calendar/preferences/timezones.dtd ingelezen in trunk en 1.8branch als
> gevolg van Engelse check in.

Zie hiervoor ook mijn patch in bug 298795.

> Off topic: Hoe kan ik me inschrijven dat ik ook op de hoogte wordt gebracht als
> er nieuwe bugs over de nederlandse vertaling ingechecked worden?

Bugs voor nl localisatie worden gemeld aan dutch.nl@localizations.bugs, je kan dus gewoon aangeven in je voorkeuren dat je dit e-mailadres ‘watcht’.


    
    

    
  
(In reply to comment #50)
> /chrome/calendar/preferences/timezones.dtd ingelezen in trunk en 1.8branch als
> gevolg van Engelse check in.
> 
> Off topic: Hoe kan ik me inschrijven dat ik ook op de hoogte wordt gebracht als
> er nieuwe bugs over de nederlandse vertaling ingechecked worden?
> 

Entities in ./chrome/calendar/preferences/timezones.dtd don't match:
  In /builds/tinderbox/Sunbird-Trunk-l10n/Darwin_8.8.1_Clobber/mozilla/calendar/locales/en-US: (add these keys to you localization)
    pref.timezone.Asia.Macau
  In /builds/tinderbox/Sunbird-Trunk-l10n/Darwin_8.8.1_Clobber/mozilla/../l10n/nl/calendar: (remove these keys from your localization)
    pref.timezone.Asia.Macao

    
    

    
  
(In reply to comment #52)

> 
> Entities in ./chrome/calendar/preferences/timezones.dtd don't match:
>   In
> /builds/tinderbox/Sunbird-Trunk-l10n/Darwin_8.8.1_Clobber/mozilla/calendar/locales/en-US:
> (add these keys to you localization)
>     pref.timezone.Asia.Macau
>   In
> /builds/tinderbox/Sunbird-Trunk-l10n/Darwin_8.8.1_Clobber/mozilla/../l10n/nl/calendar:
> (remove these keys from your localization)
>     pref.timezone.Asia.Macao
>
Sorry typfoutje. Heb het ondertussen rechtgezet. 

(In reply to comment #51)
 
> Zie hiervoor ook mijn patch in bug 298795.
> 
Wat heeft deze bug hiermee te maken? Ik vind daar ook geen patch in (voor nederlands...) van jou... sorry

    
    

    
  
(In reply to comment #53)

> (In reply to comment #51)
> 
> > Zie hiervoor ook mijn patch in bug 298795.
> > 
> Wat heeft deze bug hiermee te maken? Ik vind daar ook geen patch in (voor
> nederlands...) van jou... sorry
> 
Hij bedoeld waarschijnlijk bug 289795


    
    

    
  
(In reply to comment #54)
> waarschijnlijk bug 289795

Inderdaad, sorry typfoutje.  A propos typfoutje: hoe kan dit gebeuren:

(In reply to comment #53)
> >     pref.timezone.Asia.Macau
> >     pref.timezone.Asia.Macao
> >
> Sorry typfoutje. Heb het ondertussen rechtgezet. 

Ik zou toch sterk aanraden voor zulke dingen knippen en plakken te gebruiken!

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Typo (Argentinaië) (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Wat betreft Hendriks aangehaalde patchdeel in bug 289795 (att 263909):

calendar/chrome/calendar/dateFormat.properties
-day.1.short=Zo
+day.1.short=Z
 e.v.
Deze wijzigingen zijn m.i. niet nodig; ook en-US gebruikt hier meerdere tekens sinds rev. 1.9.

calendar/installer/custom.properties
-ICONS_STARTMENU=In mijn map &Programma’s van het menu Start
+ICONS_STARTMENU=In mijn map &Programma\U2019s van het menu Start

Ik niet of het zinvol is om hier, nu bekend is dat ook UTF in .properties mag worden gebruikt (en omwille van consistentie met FF/TB) nu voor de ’ (weer) een \2019-notatie te gaan gebruiken. Hetzelfde gebeurt immers ook niet voor bv. ë etc. (?) Toegegeven, beide komen nu voor in de hele tree en ook dat is niet consistent; wat dat betreft is \2019 voor alle .properties-bestanden misschien toch beter. Hoe gaan we hier mee om?

    
    

    
  
Ik ben vóór UTF-8, dat is tenminste leesbaar en typbaar zonder de charmap te openen om de karaktercode te vinden. Oh, en moet ik mij ook altijd nog herinneren wat precies de notatie is, want dat verschilt ook weer per bestandsformaat.

Kortom, UTF-8 ftw! ^_^

    
    

    
  
(In reply to comment #58)
> Oh, en moet ik mij ook altijd nog
> herinneren wat precies de notatie is, want dat verschilt ook weer per
> bestandsformaat.

Het feit dat de patch \U2019 gebruikt en jij het over \2019 hebt is hier wel weer een goede illustratie van ^_^. \2019 is Javascript notatie... geloof ik.

~Grauw

    
    

    
  
Comment on attachment 265253 [details] [diff] [review]
Typo (Argentinaië)

Patch toegepast op 1.8 branch en trunk.

        Attachment #265253 -
        Attachment is obsolete: true
Blocks: 375873

    
    

    
  
(In reply to comment #60)
Koen, if this patch is necessary for Sunbird 0.5 the changes also need to be checked in to SUNBIRD_0_5_BRANCH and tagged with SUNBIRD_0_5_RELEASE/LIGHTNING_0_5_RELEASE. I suggest to contact lilmatt about this topic.

    
    

    
  
fout voor de accesskey van 'nieuw agendabestand' (K) -> b
toegepast op 1.8 branch en trunk en 0.5branch

gevraagd om getagd te worden in bug 375873

    
    

    
  
Ik heb zonet Calendar gebruikt, en kreeg deze keuzes in het ‘Agendawaarschuwing’-venster:

   Wegdoen

en

   Alle wegdoen

Vind ‘wegdoen’ een beetje een raar woord. Ik weet niet wat het oorspronkelijke Engels zegt, maar verwijderen of verbergen of iets anders lijkt mij beter dan dit.

~Grauw

    
    

    
  
(In reply to comment #63)
> 
> Vind ‘wegdoen’ een beetje een raar woord. Ik weet niet wat het
> oorspronkelijke Engels zegt, maar verwijderen of verbergen of iets anders lijkt
> mij beter dan dit.

Het is inderdaad een ietwat lastige term (waar ik ook niet helemaal tevreden over was) die niet zo vaak voorkomt in vertalingen en wellicht daardoor niet her en der is terug te vinden in bekende vertaallijsten. Waar het om gaat is 'dismiss'; een beetje zoeken leerde dat het misschien beter is om hier iets als Afwijzen of nog beter, Afstellen te gebruiken. Onder de voorwaarde dat het om het daadwerkelijk uitschakelen gaat natuurlijk (dus geen sluimeren), maar dat is meen ik ook het geval. Om dezelfde reden lijkt Wegdrukken geen goed idee..


    
    

    
  
Dismiss, hm. Wel, het hoeft niet letterlijk te zijn. Kandidaten:

Agendawaarschuwing...
- verwijderen (zo heet het in het Firefox Downloads venster)
- verbergen
- opruimen (ook van het Firefox Downloads venster)
- wissen
- verwerpen
- vrijgeven (er... :))

Vind de eerste wel prima, en anders de tweede. Zou me niet druk maken dat de gebruiker eventueel zou denken dat het het item van de agenda haalt. Omdat het over een agendawaarschuwing gaat kan je best over het verwijderen daarvan spreken denk ik. Zoals ik al aangeef, wordt het ook zo in de downloadmanager van Firefox gebruikt, daar kan het ook zowel op de het item in de downloadmanager of het gedownloadde bestand slaan, een vergelijkbare situatie.

Als het om sluimeren gaat dan is "uitstellen" de correcte term denk ik.

    
    

    
  
Je hebt dus de keuze tussen
"sluimeren" voor "x minuten"
"wegdoen"
"alle wegdoen"

Sluimeren lijkt me een goede term, alsook uitstellen.
Wat wegdoen betreft heb je gelijk dat dit beter kan vervangen worden. Dan zou ik verkiezen voor het 'verwijderen'. (parallel aan Firefox download venster)

grz

    
    

    
  
(In reply to comment #65)

Hmm.. ik denk dat de vergelijking met de termen van het Firefox-downloadsvenster (niet het 'Firefox Downloads venster' trouwens; ik betrap jou toch hopelijk niet op onnodig spatiegebruik?? ;-) ) niet helemaal opgaat (omdat dismiss daar niet wordt gebruikt), maar begrijp je bedoeling. Daarin gaat het inderdaad om items in een lijst, terwijl het bij een agendawaarschuwing om het afstellen ervan gaat, ofwel het van zijn werking ontdoen (zie answers.com voor dismiss, 1 ->To end the employment or service of..). Hoe dan ook, gisteren redeneerde ik per ongeluk vanuit een 'alarm', waarbij de term afstellen vrij gangbaar is, maar als het om een waarschuwing gaat is Verwijderen misschien toch de betere/beste optie. De overige 4 die je noemde lijken me niet erg geschikt. Wel bestaat zoals je al aangaf de kans op verwarring over het van de agenda halen of niet, wat ik eigenlijk een tikkeltje bezwaarlijk vind. Maar in de praktijk zal men niet vaak meer omkijken naar oude waarschuwingen en dit wel meevallen..

Overigens vraag ik me wel al langer af waarom Alarm Waarschuwing is geworden; ik zou liever Alarm erin laten en vervolgens dus Afstellen gebruiken, waarmee het probleem ook is opgelost. Doet MS het ook niet zo?

    
    

    
  
Hier even het lemma ‘dismiss’ in de Grote Van Dale Engels-Nederlands:

0.1 laten gaan -> wegsturen 0.2 ontslaan -> opzeggen 0.3 van zich afzetten -> uit zijn gedachten zetten 0.4 afdoen -> zich (kort) afmaken van, verwerpen, v. tafel vegen, wegwuiven 0.5 (jur.) niet ontvankelijk verklaren -> afwijzen 0.6 (mil.) afdanken -> laten inrukken... en dan enkele voorbeeldzinnen, die jammer genoeg niet echt passen.

Bij ‘dismissal’ staat o.a. ‘het terzijde schuiven -> verwerping, het afdoen’.  Ik denk dat ‘verwerpen’ wel een goede optie is, verwijderen of afstellen vind ik ook goed.

    
    

    
  
Nouja, ‘verwerpen’ is beter dan ‘wegdoen’. Maar het klinkt nog steeds een beetje vreemd. Vraag me af of we dan niet al te krampachtig het oorspronkelijke Engelse woord direct proberen te vertalen.

‘Wilt u deze agendawaarschuwing verwerpen?’

Nuja, het kan, maar verwerpen heeft wel een beetje een ‘zware’ bijklank, als je begrijpt wat ik bedoel. De term wordt volgens mij alleen in formele beslissingen gebruikt (rechtszaken, vergaderingen), en niet echt op deze manier.

    
    

    
  
(In reply to comment #69)
> Vraag me af of we dan niet al te krampachtig het
> oorspronkelijke Engelse woord direct proberen te vertalen.

Met zo dicht mogelijk bij het Engels blijven lijkt me niets mis, als het mogelijk is althans.

> maar verwerpen heeft wel een beetje een ‘zware’ bijklank,
> als je begrijpt wat ik bedoel. De term wordt volgens mij alleen in formele
> beslissingen gebruikt (rechtszaken, vergaderingen), en niet echt op deze
> manier.

Helemaal mee eens, in deze context zeker niet geschikt.


    
    

    
  
aanpassingen aan trunk en 1.8 branch volgens bugs: 34049, 371916, 386430

zou ik een nieuwe bug openen voor v0.7 of deze gewoon hernoemen? (mijn voorkeur gaat eigenlijk uit naar deze te hernoemen.)

    
    

    
  
Aanpassingen in trunk en 1.8 branch volgens bugs: 355731, 383860, 352433, 386639, 372868, 387302, 385900, 374566, 384779, 378270, 385743, 386370, 389303, 377620

In bug 385900 wordt het woord Pane gebruikt. In het frans is dit Panneau. Ik heb dit als paneel vertaald, maar ben er zelf niet echt gelukkig mee... Wat zijn hiervoor goede alternatieven?

Wat betreft bug 389303 (Use one ellipsis character (...) instead of three dots (...) in titles): ik denk dat ik ze allemaal heb gehad, maar ik weet niet hoe ik hierop kan zoeken... (binnen nl files)) Hoe kan ik dit nakijken?

Wat betreft wegdoen: Vervangen door verwerpen? of toch afstellen (vind ik nogal "Nederlands" en totaal niet Vlaams, maar we blijven natuurlijk een Nederlandse vertaling maken...)


    
    

    
  

      
      
      
      

        Attached patch
          
          
        Correcties t/m 22/8 (obsolete)
        — 
          — Splinter Review
      

    


  
(In reply to comment #71)
>
> zou ik een nieuwe bug openen voor v0.7 of deze gewoon hernoemen?

Een van de developers op irc zei dat een nieuwe handiger leek, maar dat de keuze vrij is om de huidige te hernoemen. Daar hier al e.e.a. voor 0.7 staat lijkt me dat ook wel het beste.

(In reply to comment #72)
> In bug 385900 wordt het woord Pane gebruikt. In het frans is dit Panneau. Ik
> heb dit als paneel vertaald, maar ben er zelf niet echt gelukkig mee... Wat
> zijn hiervoor goede alternatieven?

Ik meen dat voor venster is gekozen, als daarmee een deel van een venster wordt bedoeld (als in message pane). Bij instellingenvensters wordt echter wel panelen gebruikt.

> Wat betreft bug 389303 (Use one ellipsis character (...) instead of three dots
> (...) in titles): ik denk dat ik ze allemaal heb gehad, maar ik weet niet hoe
> ik hierop kan zoeken... (binnen nl files)) Hoe kan ik dit nakijken?

Grep "..." of een andere handige zoektool? Ik kwam ze niet meer tegen (op de ini na, maar die blijft wellicht zo..)
 
> Wat betreft wegdoen: Vervangen door verwerpen? of toch afstellen (vind ik nogal
> "Nederlands" en totaal niet Vlaams, maar we blijven natuurlijk een Nederlandse
> vertaling maken...)

Goed gezien. ;) Naast het feit dat verwerpen eigenlijk to discard is (en ook al zo voorkomt) en erg formeel heb ik sterk het vermoeden dat ten onrechte het Engelse alarm voor alert is aangezien. Vervangen door alarm en gebruik van afstellen lost dit dus op. Waarschuwingen betreffen immers veelal systeemmeldingen en zijn bovendien niet te 'snoozen'..

    
    

    
  
Aanvullingen van gisteren gechecked en een foutje gevonden.
chrome/calendar/preferences/connection.dtd heeft twee entities die enkel in 1.8 branch voorkomen en niet in trunk.

> Een van de developers op irc zei dat een nieuwe handiger leek, maar dat de
> keuze vrij is om de huidige te hernoemen. Daar hier al e.e.a. voor 0.7 staat
> lijkt me dat ook wel het beste.

Ik heb bij deze (normaal) de bug hernoemd. (towards 1.0)

> Ik meen dat voor venster is gekozen, als daarmee een deel van een venster  
> wordt bedoeld (als in message pane). Bij instellingenvensters wordt echter wel
> panelen gebruikt.

Ik vermoed dat venster de betere zal zijn. Ik zal eens nakijken waarvoor het juist gebruikt wordt.

> Vervangen door alarm en gebruik van
> afstellen lost dit dus op. Waarschuwingen betreffen immers veelal
> systeemmeldingen en zijn bovendien niet te 'snoozen'..

Hierin kan ik wel komen. Dan moeten alle vermeldingen van waarschuwingen vervangen worden door alarmen. 


Summary: Dutch (nl) translation of calender to v0.5 → Dutch (nl) translation of calender to v1.0

    
    

    
  


  
Alarm komt overigens ook elders al een paar maal voor.

Denk je btw wel aan de freeze van volgende week? ;)

    
    

    
  
Comment on attachment 278807 [details] [diff] [review]
waarschuwing -> alarm + afstellen

Patch toegepast op trunk en 1.8_BRANCH.

        Attachment #278807 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 277829 [details] [diff] [review]
Correcties t/m 22/8

Toegepast op trunk en 1.8_branch

        Attachment #277829 -
        Attachment is obsolete: true

    
    

    
  
Aanpassingen in trunk en 1.8_branch volgens bugs 373761, 386706, 393104, 393844, 361977, 392584, 278139, 391082 

Nog een puntje:
Attendees is momenteel vertaald door aanwezigen.
Kan dit vertaald worden door 'deelnemers' of 'gasten'?


    
    

    
  
Vind ‘aanwezigen’ beter dan ‘deelnemers’… ‘gasten’ lijkt me geen goede vertaling.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Utf-8 e.a. (30/8) (obsolete)
        — 
          — Splinter Review
      

    


  
Foutjes n.a.v. wijzigingen van eergisteren en wat kleine aanvullingen zoals tijdseenheden en de 2 wijzigingen in en_US van 31/8.

(In reply to comment #78)
> Kan dit vertaald worden door 'deelnemers' of 'gasten'?

'Aanwezigen' lijkt me wel voldoen, ondanks het onlogische 'aanwezigen uitnodigen'. Hetzelfde geldt voor deelnemers, wat misschien beter past bij een wedstrijd of vergadering (wat het niet altijd is in een agenda).

    
    

    
  
Comment on attachment 279229 [details] [diff] [review]
Utf-8 e.a. (30/8)

Toegepast op 1.8branch en trunk:
- Utf-8 e.a. (30/8)
- Vertalingen volgens bugs 394191, 385916

        Attachment #279229 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Downloadstrings, key, gdata (obsolete)
        — 
          — Splinter Review
      

    


  
Kleine correctie op vorige patch (downloadstrings), 1 dubbele key en Google-eis voor gdata.dtd.

    
    

    
  
(In reply to comment #82)
> Created an attachment (id=279789) [details]
> Downloadstrings, key, gdata

-<!ENTITY gdata-provider.label "Google Calendar">
+<!ENTITY gdata-provider.label "Google Agenda">

Dit is volgens mij geen goed idee, daar het hier om de naam van een dienst gaat.

    
    

    
  
Comment on attachment 279789 [details] [diff] [review]
Downloadstrings, key, gdata

Toegepast op trunk en 1.8branch

        Attachment #279789 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #83)
> -<!ENTITY gdata-provider.label "Google Calendar">
> +<!ENTITY gdata-provider.label "Google Agenda">
> 
> Dit is volgens mij geen goed idee, daar het hier om de naam van een dienst
> gaat.

Mee eens. Waarom is dit ingechecked?

    
    

    
  
Never mind, bij Google heet het ook Google Agenda (insert bouncy smiley face here :)). Had wel in het commentaar geplaatst mogen worden om mijn bovenstaande verwarring te voorkomen.

http://www.google.com/intl/nl/googlecalendar/tour.html

    
    

    
  
sorry voor het niet toelichten...
We hadden dit nagevraagd hoe het moest vertaald worden, en bleek dat dit was zoals google het zelf vertaalde...


    
    

    
  
(In reply to comment #87)
> sorry voor het niet toelichten...
> We hadden dit nagevraagd hoe het moest vertaald worden, en bleek dat dit was
> zoals google het zelf vertaalde...

Om precies te zijn heb ik na indienen van att 277829 nagevraagd (bij Fallen) of het commentaar in gdata.properties ook van toepassing was op gdata.dtd. Het antwoord was ja, vandaar.

(In reply to comment #86)
> Had wel in het commentaar geplaatst mogen worden om mijn bovenstaande
> verwarring te voorkomen.

Je kunt ervan uitgaan dat e.e.a. zorgvuldig is gecheckt, en had het kunnen zien in het/de betreffende bestand(en).. ;)


    
    

    
  

      
      
      
      

        Attached patch
          
          
        calendardeel van patch Hendrik (obsolete)
        — 
          — Splinter Review
      

    


  
calendardeel van Attachment 280454 [details] [diff] for Bug 289795

    
    

    
  
(In reply to comment #89)
> Created an attachment (id=280460) [details]
> calendardeel van patch Hendrik

Prima.

Ter info: ik had even twijfels over categories.properties aangezien dezelfde wijziging in het verleden problemen heeft gegeven, dacht bij 0.3. Het bestand lijkt echter obsolete te zijn of te gaan worden; volgens ssitter worden categorieën immers uit sunbird-l10.js gehaald, dus geen probleem.

    
    

    
  
Ik heb een forum-topic geopend om wat meer mensen de vertalingen te laten nalezen... http://www.mozbrowser.nl/forum/viewtopic.php?p=80681#80681

dit is wat er als reactie uitkwam:
[quote=Nirwana]Wil ik een nieuwe gebeurtenis toevoegen, dan staat er Start en Einde.
Wil ik een nieuwe taak toevoegen, dan staat er Start en Einddatum.
Dat is niet geheel consistent, maar ik zit vooral met het woord Start. Bij Start denk ik vrijwel direct aan Finish (als van een wedstrijd). Bij Begin denk ik direct aan Eind. Ik zou daarom denken dat al deze termen iets met Begin en Eind zouden moeten zijn.[/quote]

Ikzelf struikel niet over start/eind, maar heb ook geen bezwaar tegen begin/eind
Wat is jullie idee hierover?

    
    

    
  
(In reply to comment #91)
> Ikzelf struikel niet over start/eind, maar heb ook geen bezwaar tegen
> begin/eind
> Wat is jullie idee hierover?

Begin/eind klinkt beter.

    
    

    
  
(In reply to comment #92)
> Begin/eind klinkt beter.

Mee eens.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Keys e.a. (obsolete)
        — 
          — Splinter Review
      

    


  
Wat wijzigingen in sun-calendar-event-dialog.dtd, vnl. access keys.

Op 1 na lukte het om de keyconflicten eruit te krijgen, maar het lijkt erop dat 0 niet mogelijk is gezien het gebrek aan keys, of liever gezegd het niet voorkomen van de nog vrije letters. Echter, omdat voor de velden Begin en Einde in een gebeurtenisvenster toch nog tab-kliks vereist zijn om in het gewenste veld te komen (quote: <ssitter> the accesskeys work but the datepicker control doesn't reacts correctly on them) is het misschien een idee om net als bij de vorige release deze keys (dacht aan n resp. u) achterwege te laten zodat dit niet opvalt. Daardoor wordt ook voorkomen dat ondanks het tegen Mozilla's policy's ingaande beleid geen letters als j, q, p etc. te gebruiken elders een j nodig is, en de reeds gebruikte g bevalt me al niet.. :-/

Ook nog link->koppeling en 3 andere termen die me dwars zaten: zoomen omdat volgens mij het werkwoord wordt bedoeld, wat overigens volgens VD wel bestaat maar als znw. een andere betekenis heeft. Voorgestelde tijd-plaats spreekt denk ik voor zich, en reminder.due.label aangepast naar hoe het in het Engels gaat worden door bug 395925, die is ontstaan uit de vraag op irc wat hier nu precies met de oude werd bedoeld, vooral m.b.t. 'due'. Wellicht dat er nog meer met 'due' in de teksten staat waar nog even gekeken moet worden, evenals die met 'start'.

Begin voor Start lijkt me inderdaad de primaire betekenis, dus geen probleem en is hierin meegenomen. De (op het forum) genoemde inconsistentie in Einde/Einddatum is te wijten aan en-US en het gewillig volgen ervan, maar deze is naar mijn idee verklaarbaar omdat gebeurtenissen doorgaans geen vaste einddatum hebben en taken wel. M.a.w. het Engelse Due date staat voor een datum dat iets verwacht wordt klaar te zijn (hetgeen hier niet is 'meevertaald'), terwijl die bij een gebeurtenis nagenoeg vastligt. 'Verwachte einddatum' voor task.to.label behoort dus ook tot de mogelijkheden om dit onderscheid duidelijk te maken, maar ik voel er niet veel voor, o.a. omdat het ook een onzekerheid aanduidt. Hetzelfde geldt voor 'Geplande'.

Koen: kun je in custom.properties in de 1.8-branch bij ICONS_QUICKLAUNCH 'starten' nog even een kleine letter geven? (Zie bug 289795 attachment 277416 [details] [diff] [review])

    
    

    
  
Comment on attachment 280711 [details] [diff] [review]
Keys e.a.

Patch toegepast op trunk en 1.8branch
Ook custum.properties aangepast.

        Attachment #280711 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #95)
> Ook custum.properties aangepast.

Het is nu fout in zowel trunk als branch, alleen Snel is met een hoofdletter.. (dacht dat het verzoek toch duidelijk genoeg was?)


    
    

    
  
(In reply to comment #96)
> (In reply to comment #95)
> > Ook custum.properties aangepast.
> 
> Het is nu fout in zowel trunk als branch, alleen Snel is met een hoofdletter..
> (dacht dat het verzoek toch duidelijk genoeg was?)
> 

Aangepast.
Sorry Ton, had je verzoek verkeerd begrepen. Nu ik het terug lees, was het duidelijk genoeg, ...


    
    

    
  

      
      
      
      

        Attached patch
          
          
        Enkele keys, Begin, agenda (obsolete)
        — 
          — Splinter Review
      

    


  
- Enkele keyconflicten die niet direct opvielen in Lightning (2*n, 2*v, g>b)
- Start -> Begin
- Calendar->agenda

De huidige inconsistentie in Einddatum (Due date) in taakinstellingen en Verval (Due) in de tooltip en taakkolommen zit me nog niet lekker. Willen we dit zo laten, wordt Einddatum ondanks de eigenlijk onjuiste betekenis toch Vervaldatum, Verval daarentegen iets als Einde of is er nog iets beters? Ter info: MS lijkt bij taken naast Startdatum Einddatum te gebruiken, al weet ik dat enkel via Google (iemand die MS Agenda gebruikt?).

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Typo, keys, remote (obsolete)
        — 
          — Splinter Review
      

    


  
Een lang gemiste typo, 2 kleine keyoptimalisaties/aanvullingen en wat meer consistentie in ‘op andere computer’ (remote) c.q. ‘verversen’.

    
    

    
  
Comment on attachment 281107 [details] [diff] [review]
Enkele keys, Begin, agenda

Patch toegepast op trunk en branch
Sorry voor de vertraging...

        Attachment #281107 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 281137 [details] [diff] [review]
Typo, keys, remote

patch toegepast op trunk en branch
sorry voor de vertraging...

        Attachment #281137 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #75)
> Created an attachment (id=278807) [details]
> waarschuwing -> alarm + afstellen
> 
> Alarm komt overigens ook elders al een paar maal voor.
> 
> Denk je btw wel aan de freeze van volgende week? ;)

Ik kreeg zonet ‘afstellen’ te zien en moest drie keer met mijn ogen knipperen voordat ik door had dat ik op die knop moest drukken (ook al heb ik het venster in 0.5 ook al vaak gezien dus had ik het voordeel van bekendheid).

Dus we moeten het denk ik toch nog anders doen, verwijderen bijvoorbeeld.

(En nee Ton, dit zeg ik niet om jou te sarren.)

~Grauw

    
    

    
  
Volgens de online van Dale is afstellen ook niet het juiste woord: http://www.vandale.nl/opzoeken/woordenboek/?zoekwoord=afstellen
Naar mijn mening is uitschakelen of afzetten een juistere benaming.

    
    

    
  
Afstellen heb ik altijd als een zuiver Nederlands woord gezien dat niks met vlaams te maken had.
Verwijderen vond ik een redelijke vertaling, maar ook uitschakelen vind ik geen slecht voorstel...
Bij afzetten denk ik onmiddelijk aan een toestel dat moet uitgeschakeld worden (afgezet worden)

grz

    
    

    
  
Wat betreft het afstellen: Wat vinden jullie van 'uitschakelen', uitzetten', 'afzetten'
-> Hier vind ik 'uitzetten' het minst sterke.

Verder heb ik updates in trunk en 1.8_branch gedaan:
- chrome/calendar/calendar.properties
- chrome/calendar/menuOverlay.dtd


    
    

    
  
Ik vind uitzetten wel het beste juist, maar uitschakelen is ook wel goed. Van deze drie zinnen zou ik de tweede zelf zeggen:

"Ik schakel het alarm van mijn wekker uit."
"Ik zet het alarm van mijn wekker uit."
"Ik zet het alarm van mijn wekker af."

Uitschakelen is denk ik meer van toepassing als het om een apparaat gaat. Afzetten heeft bij mij toch primair een andere betekenis dan uitschakelen, en zou ik ook nooit zeggen over mijn wekker (zie voorbeeld hierboven), dus dat vind ik niks.

~Grauw

    
    

    
  
(Goede suggesties overigens! Zeker nu het agenda-alarm heet i.p.v. agendawaarschuwing. Veel beter dan verwijderen e.d..)

    
    

    
  
Aanpassing in trunk en 1.8_branch:
- chrome/lightning/lightning.dtd (bug 379204, 396159, 396547, 253396)
- chrome/calendar/calendar.dtd (bug 396337, 253396, 405127, 406849,341576)
- chrome/prototypes/sun-calendar-event-dialog.dtd (bug 395925, 341518, 400279)
- chrome/calendar/calendar.properties (bug 395940,341576)
- chrome/calendar/global.dtd (bug 341518, 399595)
- chrome/calendar/calendar-recurrence-dialog.dtd (bug 403748)
- chrome/calendar/preferences/connection.dtd (bug 395051 - enkel 1.8_branch)
- chrome/calendar/wcap.properties (bug 405109)


    
    

    
  
Aanpassingen in trunk en 1.8_branch:
chrome/calendar/calendar.dtd (389854 & 402177)
chrome/calendar/menuOverlay.dtd (402177 & 409842)
chrome/calendar/aboutDialog.dtd (410140)

Hierna nog een typfoutje rechtgezet.

    
    

    
  
Aanpassingen in trunk en 1.8_branch

    
    

    
  
Aanpassingen in trunk en 1.8_branch (Bug 376585)
chrome/calendar/calendar.dtd
chrome/calendar/calendar-subscriptions-dialog.dtd

    
    

    
  

      
      
      
      

        Attached patch
          
          
        afstellen -> uitschakelen (obsolete)
        — 
          — Splinter Review
      

    


  
Naar aanleiding van de komende 0.8 release, zou ik graag overeenkomst hebben wat betreft het 'afstellen':
Ik stel voor om dit te veranderen door 'uitschakelen'. Uitzetten vind ik ook wel ok, maar uitschakelen voelt natuurlijker aan voor mij...
Iedereen mee akkoord? dan check ik de patch in...

    
    

    
  
Mijn zegen heb je!

    
    

    
  
Comment on attachment 296397 [details] [diff] [review]
afstellen -> uitschakelen

patch ingechecked in trunk en 1.8_branch

        Attachment #296397 -
        Attachment is obsolete: true

    
    

    
  
Aanpassingen in trunk en 1.8_branch (bug 379029)
chrome/calendar/providers/gdata/gdata.dtd


    
    

    
  
Uitschakelen is wel in orde, dus check maar in. (..)

Uitzetten/Afzetten van een wekker/wekalarm is in het Nederlands het meest gebruikelijk maar meer spreektaal, dus blijft uitschakelen over. Afstellen van een alarm is, los van wat Van Dale zegt, op zich ook niet ongewoon, maar dit is dan meer van toepassing op oproep-, brand- en inbraakalarmen etc. Wellicht dat dit van enige invloed is geweest voor mijn keuze ervan boven het reeds in comment 64 genoemde Uitschakelen; een echte vertaalfout zoals gesteld in bug 401205 lijkt het me i.i.g. niet, mede gezien het eerdere overleg.

Ik zie overigens nieuwe foutjes Koen, kijk e.e.a. nog even kritisch na als je wilt.

    
    

    
  
Aanpassingen in trunk en 1.8_branch:
chrome/calendar/calendar.dtd (393395, 411497, 411498, 389952)
chrome/calendar/calendar.properties (393395, 328618, 411498)
chrome/lightning/lightning.properties (387863)

Dit is het voor nu. 
Aangezien de uiterste datum voor de vertaling op 7/2 ligt, zal ik proberen om zo vlug mogelijk alles klaar te hebben. 


    
    

    
  
Aanpassingen in trunk en 1.8_branch: (408798)
chrome/calendar/calendar.dtd
chrome/lightning/lightning.dtd


    
    

    
  
Aanpassingen in trunk en 1.8_branch:
chrome/calendar/calendar.dtd
chrome/lightning/lightning.dtd
chrome/lightning/lightning.properties

    
    

    
  


  
Incl. aanvulling calendar.properties ->1.96, hier en daar een uitlijning, tab weg en wat witregels.

    
    

    
  
Comment on attachment 301827 [details] [diff] [review]
Correcties en wijzigingen t/m 06/02

Patch toegepast op 1.8 branch en trunk
Met dank aan Ton.

        Attachment #301827 -
        Attachment is obsolete: true

    
    

    
  
Aangepast in trunk en 1.8_branch: Bug 416098

chrome/calendar/calendar.dtd
chrome/calendar/menuOverlay.dtd
chrome/lightning/lightning.dtd

    
    

    
  


  

    
    

    
  
Comment on attachment 301971 [details] [diff] [review]
Vergeten zin, apostrofen, spatie en 2 keys

Toegepast op 1.8_branch en trunk

    
    

    
  
Comment on attachment 301971 [details] [diff] [review]
Vergeten zin, apostrofen, spatie en 2 keys

sorry, vergeten obsolete te zetten...

        Attachment #301971 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #121)
> Created an attachment (id=301827) [details]
> Correcties en wijzigingen t/m 06/02
> 
> Incl. aanvulling calendar.properties ->1.96, hier en daar een uitlijning, tab
> weg en wat witregels.

Die witregels zou ik liever proberen vermijden.  Ik zie er de zin niet echt van, en het is verwarrend als je door de geschiedenis van het bestand bladert om bv. een fout te vinden die ergens geïntroduceerd is.  Hetzelfde met uitlijning: als het duidelijker wordt, ok, maar liefst niet te vaak.  (Ik geef toe dat dit voor bestanden met slechts strings niet zo relevant is, maar je weet nooit.  Wie al eens in code naar een bug gezocht heeft met revisiecontrole weet hoe vervelend dit is.)

+<!ENTITY calendar.task.delete.button.tooltip    "De gelecteerde taak verwijderen">

geSElecteerd

-<!ENTITY calendar.context.markcompleted.label     "Voltooid markeren">
+<!ENTITY calendar.context.markcompleted.label     "Voltooide markeren">

Moet dit niet zijn ‘Als voltooid markeren’?


    
    

    
  

      
      
      
      

        Attached patch
          
          
        Access keys en correcties (obsolete)
        — 
          — Splinter Review
      

    


  
(In reply to comment #127)
> 
> Die witregels zou ik liever proberen vermijden.  Ik zie er de zin niet echt
> van, en het is verwarrend als je door de geschiedenis van het bestand bladert

Ik zorg er alleen voor dat het bestand qua opbouw identiek blijft aan de Engelse versie, en ik raad iedereen aan hetzelfde te doen. Ten eerste om de verschillen duidelijk in beeld te hebben in de lokaal gebruikte diff-tool, en ten tweede omdat ook revisiegeschiedenis beter leesbaar is als zowel regelnummering als horizontale uitlijning zo veel mogelijk overeenkomt.

> geSElecteerd
> 
> Moet dit niet zijn ‘Als voltooid markeren’?

Goed gezien, maar het laatste liever omgedraaid.

    
    

    
  
Comment on attachment 302354 [details] [diff] [review]
Access keys en correcties

Patch toegepast op trunk en 1.8branch.

Wat ik me wel afvraag:
-<!ENTITY calendar.new.server.label              "Nieuw agendabestand…">
+<!ENTITY calendar.new.server.label              "Nieuwe agenda…">
Moeten we dan niet alle 'agendabestand' vervangen door 'agenda' zodat het consequent blijft?

        Attachment #302354 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        2 keyconflicten (obsolete)
        — 
          — Splinter Review
      

    


  
.. in prefs/update (SB), overige iets meer als in TB/FF.

(In reply to comment #129)
> 
> Wat ik me wel afvraag:
> -<!ENTITY calendar.new.server.label              "Nieuw agendabestand…">
> +<!ENTITY calendar.new.server.label              "Nieuwe agenda…">
> Moeten we dan niet alle 'agendabestand' vervangen door 'agenda' zodat het
> consequent blijft?

Het ziet er naar uit dat op deze plek ten onrechte sprake was van ‘kalenderbestand’. De term komt elders ook wel voor maar nu alleen daar waar het Engels het ook gebruikt. Het lijkt ook niet logisch het er hier in te houden (omwille van gewenning o.i.d.). Zelf vind ik het verwarrend; een agenda op afstand is immers iets anders dan een bestand.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        2 keys (obsolete)
        — 
          — Splinter Review
      

    


  
De w->e vergeten in een eerdere, cosmetisch. Idem voor de S; dit is wat meer à la FF/TB.

    
    

    
  
Wat ik me afvraag:

 <!ENTITY pref.calendar.advanced.update.autoCheck.label "Automatisch controleren op updates voor:">
 <!ENTITY pref.calendar.advanced.update.enableAppUpdate.label "&brandShortName;">
-<!ENTITY pref.calendar.advanced.update.enableAppUpdate.accesskey "r">
+<!ENTITY pref.calendar.advanced.update.enableAppUpdate.accesskey "C">

Moet deze accesskey niet iets zijn uit 'Sunbird'?
In de alpha versies noemt het Calendar, maar eens een RC uitkomt, wordt dit (dacht ik) Sunbird.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        2 keyconflicten v2 (obsolete)
        — 
          — Splinter Review
      

    


  
(In reply to comment #132)

> +<!ENTITY pref.calendar.advanced.update.enableAppUpdate.accesskey "C">
> 
> Moet deze accesskey niet iets zijn uit 'Sunbird'?
> In de alpha versies noemt het Calendar, maar eens een RC uitkomt, wordt dit
> (dacht ik) Sunbird.

Inderdaad, goed gezien; hetzelfde verhaal dus als Help-Over.. Ik heb de installer van 0.7 maar even getest en op beide plekken komt ‘Sunbird’ voor. De patch is aangepast (r>S).

Overigens zag ik vreemde tekens voorbijkomen i.p.v. ... aan het einde van de ‘voortgangs’strings beginnend met STATUS_ (custom.p) bij zowel de installers van 0.7 als 0.8pre. Ik dacht dat dit voor FF/TB was opgelost, dus waarom dat hier fout gaat? Er moet/kan i.i.g. nog even naar worden gekeken.

(In reply to comment #130)
> ...sprake was van ‘kalenderbestand’. De term ...

Het ging hier natuurlijk om ‘agendabestand’.

        Attachment #302767 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 303129 [details] [diff] [review]
2 keys

toegepast op 1.8branch en trunk

        Attachment #303129 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 303226 [details] [diff] [review]
2 keyconflicten v2

patch toegepast op 1.8branch en trunk

        Attachment #303226 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 280460 [details] [diff] [review]
calendardeel van patch Hendrik

Opruimen: Deze patch is allang verwerkt...

        Attachment #280460 -
        Attachment is obsolete: true

    
    

    
  


  
Het lijkt erop dat Windows 98 de ellipsis niet goed weergeeft tijdens installatie/deïnstallatie en update (=verticale balk). Aangezien Sunbird nog op Win 98 kan draaien is het wellicht beter ze hier (nog) niet te gebruiken, net als en-US.

    
    

    
  
Gewoon een vraagje:
is deze correct?
SURVEY_TEXT=&Vertel ons wat u vond van ${BrandShortName} -> SURVEY_TEXT=V&ertel ons wat u vond van ${BrandShortName}

Ik begrijp niet goed wat die '&' doet...
ik zie wel dat ze de volgende regel voor de S van starten staat en niet in het woord...

    
    

    
  
(In reply to comment #138)
> Gewoon een vraagje:
> is deze correct?
> SURVEY_TEXT=&Vertel ons wat u vond van ${BrandShortName} -> SURVEY_TEXT=V&ertel
> ons wat u vond van ${BrandShortName}

Dit is de access key, en dus strijdig met ‘Voltooien’. Zie ook de trunkbug.

Overigens kun je gewoon committen, maar let er wel op dat het op 3 plaatsen gebeurt (zie de aankondiging).

    
    

    
  
Lightning 0.8 RC1

In menu Agenda staat het woord Agendaeigenschappen. Dit woord leest lastig vanwege de klinkers tussen agenda en eigenschapen. Is het ook mogelijk om hier een spatie tussen te zetten?


    
    

    
  
Op zich goede suggestie, maar dan wel een streepje en geen spatie.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        ->Agenda-eigenschappen (obsolete)
        — 
          — Splinter Review
      

    


  
(In reply to comment #140)

De taalregels stellen dat een samenstelling in principe *altijd* aan elkaar wordt geschreven (het is immers één woord), tenzij i.c.m. bv. een woordgroep of eigennaam. In het geval van klinkerbotsing (a+u=au, e+i=ei etc.) echter móet een koppelteken worden gebruikt, en in gevallen waarin het de leesbaarheid ten goede komt mág dit. Spaties binnen samenstellingen van twee of meer zelfstandige naamwoorden zijn *altijd* fout. Onterecht spatiegebruik (ook wel ‘Engelse ziekte’ genoemd) wordt overigens vaak als erg storend ervaren, en vermoedelijk is het zelfs de meest gemaakte fout naast d/t-fouten. Zie bv. www.spatiegebruik.nl en http://nl.wikipedia.org/wiki/Engelse_ziekte_(taal).

‘Agendaeigenschappen’ is dus taalkundig juist (ae vormt geen klinkerbotsing), maar omwille van leesbaarheid mag er een koppelteken in. Aangezien dit op enkele andere plaatsen in de source ook al gebeurt (bv. bij Pagina-eigenschappen) zie ik geen bezwaar. Eerlijk gezegd twijfelde ik om die reden aan het weglaten ervan ten tijde van attachment 279229 [details] [diff] [review].

    
    

    
  

      
      
      
      

        Attached patch
          
          
        ..die bevatten: (obsolete)
        — 
          — Splinter Review
      

    


  
Kleine aanpassing n.a.v. vergelijkbaar geval in TB.

    
    

    
  
> Spaties binnen samenstellingen van twee
> of meer zelfstandige naamwoorden zijn *altijd* fout. Onterecht spatiegebruik
> (ook wel ‘Engelse ziekte’ genoemd) wordt overigens vaak als erg storend
> ervaren, en vermoedelijk is het zelfs de meest gemaakte fout naast d/t-fouten.
> Zie bv. www.spatiegebruik.nl en
> http://nl.wikipedia.org/wiki/Engelse_ziekte_(taal).

Bedankt! Nu ben ik ook weer een stuk wijzer. Het ging me in de eerste plaats om de leesbaarheid. Een spatie leek mij logisch; inmiddels dus niet meer 8-)


    
    

    
  
Comment on attachment 306722 [details] [diff] [review]
Ellipsis -> ... (installer/updater)

toegepast op trunk, Mozilla_1.8_branch en Sunbird_0.8_branch

        Attachment #306722 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 308068 [details] [diff] [review]
->Agenda-eigenschappen

toegepast op trunk, Mozilla_1.8_branch en Sunbird_0.8_branch

        Attachment #308068 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 308218 [details] [diff] [review]
..die bevatten:

toegepast op trunk, Mozilla_1.8_branch en Sunbird_0.8_branch

        Attachment #308218 -
        Attachment is obsolete: true
Assignee: dutch.nl → koen.hendrickx
Status: ASSIGNED → NEW

    
    

    
  

      
      
      
      

        Attached patch
          
          
        patch van nl-NL (obsolete)
        — 
          — Splinter Review
      

    


  
Deel van een patch die ik in bug 289795 had gehangen, maar blijkbaar hier hoort.

    
    

    
  
(In reply to comment #148)
> Created an attachment (id=321452) [details]

Twee opmerkingen:

1) De wijziging in calendar.properties komt 2 keer voor in deze zin, niet 1 keer..
2) Het moet nu toch wel duidelijk zijn dat custom.properties, mui.properties, override.properties en updater.ini problemen geven met de ellipsis (na bouwen uit de branch) en dat deze daarom voor calendar bewust zijn weggelaten, c.q. al eerder zijn hersteld (!). Graag dus even de patch aanpassen (en in het vervolg s.v.p. iets meer rekening houden met de historie en bekend veronderstelde zaken..)

Overigens is de schrijfwijze ‘de-installeren’ die volgens het Groene Boekje, ‘deïnstalleren’ die volgens het Witte, maar dat enkel ter info (dat we het Groene volgen moge duidelijk zijn).


    
    

    
  
Aanpassingen in trunk en 1.8_branch:

chrome/calendar/calendar.dtd
chrome/calendar/menuoverlay.dtd
installer/custom.properties (enkel 1.8_branch)
chrome/calendar/calendarcreation.dtd
chrome/calendar/providers/gdata/gdata.dtd
chrome/calendar/preferences/timezones.dtd
chrome/calendar/calendar.properties

Wat betreft patch van Hendrik: Deze ga ik hangende laten tot een oplossing is voor de ellipsis...

    
    

    
  

      
      
      
      

        Attached patch
          
          
        deïnst -> de-inst (obsolete)
        — 
          — Splinter Review
      

    


  
deïnstalleren → de-installeren, *zonder* de ellipsis

        Attachment #321452 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #149)
> (In reply to comment #148)
> > Created an attachment (id=321452) [details] [details]
> 
> 2) Het moet nu toch wel duidelijk zijn dat custom.properties, mui.properties,
> override.properties en updater.ini problemen geven met de ellipsis (na bouwen
> uit de branch) en dat deze daarom voor calendar bewust zijn weggelaten, c.q. al
> eerder zijn hersteld (!). Graag dus even de patch aanpassen (en in het vervolg
> s.v.p. iets meer rekening houden met de historie en bekend veronderstelde
> zaken..)

Sorry hiervoor, zie nieuwe patch.

    
    

    
  
Deze is wel ok.
N.B. UninstallBtn (4x) is nog ‘Wit’. Waarschijnlijk gemist door ‘&’.

    
    

    
  
(In reply to comment #153)
> Deze is wel ok.
> N.B. UninstallBtn (4x) is nog ‘Wit’. Waarschijnlijk gemist door ‘&’.

Ah zo, ‘wit’, de spelling.  Niet dus, dat is in de nieuwe patch wel in orde.

    
    

    
  
Aanpassingen in trunk en 1.8_branch:

chrome/calendar/calendar.dtd
chrome/prototypes/sun-calendar-event-dialog.dtd
chrome/calendar/calendar-event-dialog.dtd
chrome/calendar/preferences/timezones.dtd
chrome/lightning/lightning.dtd
chrome/lightning/lightning.properties



    
    

    
  
Aanpassingen in trunk en 1.8_branch:

chrome/calendar/calendar-event-dialog.dtd 
chrome/calendar/calendar.dtd 
calendar/providers/wcap/wcap.properties 
chrome/lightning/lightning.properties 
chrome/calendar/dateFormat.properties 
chrome/calendar/calendar.properties
chrome/lightning/lightning.dtd 

Verwijderde bestanden:
chrome/calendar/wcap.properties 
chrome/prototypes/sun-lightning.dtd 

zie ook bug 438557
De patch van deze bug bevat ook andere onderdelen, waardoor ik hem niet in een keer doorvoer, maar wel onderdelen van gebruik... Dank aan Hendrik.

    
    

    
  
(In reply to comment #156)
> zie ook bug 438557
> De patch van deze bug bevat ook andere onderdelen, waardoor ik hem niet in een
> keer doorvoer, maar wel onderdelen van gebruik... Dank aan Hendrik.

Mooi en graag gedaan.  Misschien kan je de patch nu obsolete maken?

P.S. Koen, ik heb je hulp eens nodig, wanneer ben je op irc?  Mail me.


    
    

    
  
Aanpassingen in trunk en 1.8_branch:

chrome/calendar/providers/wcap/wcap.properties
chrome/calendar/calendar.properties 
chrome/calendar/calendar-occurrence-prompt.properties (zie bug 438557)
chrome/calendar/calendar-occurrence-prompt.dtd (zie bug 438557)
chrome/prototypes/sun-calendar-event-dialog.dtd 
chrome/lightning/lightning.dtd 
chrome/calendar/preferences/categories.dtd 
chrome/calendar/preferences/alarms.dtd 
chrome/calendar/migration.dtd 
chrome/calendar/menuOverlay.dtd 
chrome/calendar/global.dtd 
chrome/calendar/calendar.dtd 
chrome/calendar/aboutDialog.dtd 
chrome/branding/brand.dtd 

Verwijderde bestanden:
chrome/calendar/overlay.dtd 

Status: NEW → ASSIGNED

    
    

    
  
Aanpassingen in trunk en 1.8_branch:

chrome/calendar/calendar.properties 
chrome/lightning/lightning.properties 
chrome/calendar/providers/wcap/wcap.properties 
chrome/calendar/calendar.dtd 
chrome/calendar/preferences/timezones.dtd 
chrome/calendar/timezones.properties 
chrome/lightning/lightning.dtd
chrome/prototypes/sun-calendar-event-dialog.properties 
chrome/prototypes/sun-calendar-event-dialog.dtd 
chrome/calendar/preferences/advanced.dtd


    
    

    
  
Aanpassingen in trunk en 1.8_branch tot groene tree...

chrome/calendar/calendar.dtd 
chrome/calendar/dateFormat.properties 
chrome/calendar/menuOverlay.dtd 
chrome/calendar/providers/wcap/wcap.properties 
chrome/prototypes/sun-calendar-event-dialog.dtd

Hierna nog aanpassingen in 
l10n/nl/other-licenses/branding/sunbird/brand.dtd

    
    

    
  


  
Alles nagelopen t/m vandaag. De laatste wijzigingen in calendar.pr.. (tot 1.111) zitten er dus ook in.

O.a. keyconflicten, consistenties (met Firefox), uitlijning/witregels, tijzonebenamingen, unicode-’, spaties en enkele iets betere termen.

    
    

    
  
(In reply to comment #154)
> (In reply to comment #153)
> > Deze is wel ok.
> > N.B. UninstallBtn (4x) is nog ‘Wit’. Waarschijnlijk gemist door ‘&’.
> 
> Ah zo, ‘wit’, de spelling.  Niet dus, dat is in de nieuwe patch wel in
> orde.

Ik doelde juist op de rest van de source..

    
  
Summary: Dutch (nl) translation of calender to v1.0 → Dutch (nl) translation of calendar to v1.0

    
    

    
  
(In reply to comment #161)
Index: nl/calendar/chrome/calendar/calendar-occurrence-prompt.dtd

....
+<!ENTITY buttons.parent.accesskey "A">
\ No newline at end of file <<---

Kun je hier nadien nog een newline toevoegen? (Een nieuwe patch is wellicht wat overdreven..)


    
    

    
  
(In reply to comment #161)
> Created an attachment (id=327304) [details]
> Correcties en wijzigingen t/m 28/06
> 
> Alles nagelopen t/m vandaag. De laatste wijzigingen in calendar.pr.. (tot
> 1.111) zitten er dus ook in.

-buttons.occurrence.delete.label=Enkel dit item wissen
-buttons.occurrence.edit.label=Enkel dit item bewerken
+buttons.occurrence.delete.label=Alleen deze gebeurtenis verwijderen
+buttons.occurrence.edit.label=Alleen deze gebeurtenis bewerken

De wijziging item → gebeurtenis en wissen → verwijderen vind ik goed, maar ‘enkel’ vind ik hier duidelijker.  Met wat slechte wil kan de ‘niet met iemand anders’-betekenis van ‘alleen’ voor verwarring zorgen.

-<!ENTITY calendar.miniday.next.button.tooltip     "Gebeurtenissen voor morgen tonen">
-<!ENTITY calendar.miniday.previous.button.tooltip "Gebeurtenissen van gisteren tonen">
+<!ENTITY calendar.miniday.next.button.tooltip     "Gebeurtenissen van volgende dag tonen">
+<!ENTITY calendar.miniday.previous.button.tooltip "Gebeurtenissen van vorige dag tonen">

Ik zie niet in waarom gisteren en morgen hier weg zouden moeten.

+<!ENTITY priority.level.none                "Niet gespecificeerd">
Misschien ‘Niet opgegeven/aangegeven’?

-itemDeleteError=Er is een fout opgetreden bij het verwijderen van het item op de server.
+itemDeleteError=Er is een fout opgetreden bij het verwijderen van het item van de server.
 
Ha nee.  Het is toch op de server dat er iets misloopt.  Hier ook gebeurtenis voor item?

-<!ENTITY pref.calendar.advanced.encryption.certSelection.description "Wanneer een server mijn persoonlijk certificaat vraagt:">
+<!ENTITY pref.calendar.advanced.encryption.certSelection.description "Wanneer een server om mijn persoonlijke certificaat verzoekt:">
Hier zag ik toch liever het wat informelere ‘vragen’ behouden.

-imipSendMailOutlook2000CompatMode=Outlook 2000 en Outlook 2002/XP ondersteunen.
+imipSendMailOutlook2000CompatMode=Ondersteunen Outlook 2000 en Outlook 2002/XP.
Dit ziet er wat raar uit, wat is de context?

-summaryDueTaskLabel=Vanwege:
+summaryDueTaskLabel=Verval:
Dit is wel een straffe betekniswissel.  Wat is de context?

    
    

    
  
(In reply to comment #164)
> -<!ENTITY calendar.miniday.next.button.tooltip     "Gebeurtenissen voor morgen
> tonen">
> -<!ENTITY calendar.miniday.previous.button.tooltip "Gebeurtenissen van gisteren
> tonen">
> +<!ENTITY calendar.miniday.next.button.tooltip     "Gebeurtenissen van volgende
> dag tonen">
> +<!ENTITY calendar.miniday.previous.button.tooltip "Gebeurtenissen van vorige
> dag tonen">
> 
> Ik zie niet in waarom gisteren en morgen hier weg zouden moeten.

Omdat de focus van de calendar niet alleen ‘vandaag’ kan zijn, maar ook een andere datum.

Dit verschijnt in Lightning 0.9 als je je muis over over de < en > knopjes beweegt in de Events and Tasks-zijbalk.

> -summaryDueTaskLabel=Vanwege:
> +summaryDueTaskLabel=Verval:
> Dit is wel een straffe betekniswissel.  Wat is de context?

Verval wordt ook elders gebruikt als vertaling van ‘Due’ (zie bijv. in Taken view, de Verval kolom). Due wordt hier gebruikt als in ‘Due date’ en niet ‘Due to’.

    
    

    
  
(In reply to comment #165)
> (In reply to comment #164)
> > -<!ENTITY calendar.miniday.next.button.tooltip     "Gebeurtenissen voor morgen
> > tonen">
> > -<!ENTITY calendar.miniday.previous.button.tooltip "Gebeurtenissen van gisteren
> > tonen">
> > +<!ENTITY calendar.miniday.next.button.tooltip     "Gebeurtenissen van volgende
> > dag tonen">
> > +<!ENTITY calendar.miniday.previous.button.tooltip "Gebeurtenissen van vorige
> > dag tonen">
> > 
> > Ik zie niet in waarom gisteren en morgen hier weg zouden moeten.
> 
> Omdat de focus van de calendar niet alleen ‘vandaag’ kan zijn, maar ook een
> andere datum.

Ah ja tuurlijk.

> Dit verschijnt in Lightning 0.9 als je je muis over over de < en > knopjes
> beweegt in de Events and Tasks-zijbalk.

In 0.8 nog niet, een verbetring.

> > -summaryDueTaskLabel=Vanwege:
> > +summaryDueTaskLabel=Verval:
> > Dit is wel een straffe betekniswissel.  Wat is de context?
> 
> Verval wordt ook elders gebruikt als vertaling van ‘Due’ (zie bijv. in
> Taken view, de Verval kolom). Due wordt hier gebruikt als in ‘Due date’ en
> niet ‘Due to’.

Ik blijf het een raar woord vinden.  Ik denk dan aan een helling, en de steilheid ervan, slechts in tweede instantie aan het aflopen van iets, maar dan ook in de zin van een product dat slecht wordt, vervaldatum.  In ieder geval zou ik het kolommetje dat je in takenpaneel ziet in ‘Einde’ veranderen.  Maar ik gebruik Lightning (jammer genoeg) nog niet echt, dus het kan goed zijn dat ik enkele use-cases over het hoofd zie.


    
    

    
  
Ja ik had ook zojuist 0.9 geïnstalleerd om dat te checken, maar die is in het Engels en nu wil hij niet meer werken als ik 0.8 terug installeer :(. Zijn er Nederlandse nightlies?

M.b.t. verval, als je een betere vertaling weet, graag :). Maar ‘vanwege’ was in ieder geval niet goed.

    
    

    
  
(In reply to comment #164)
> (In reply to comment #161)
> De wijziging item → gebeurtenis en wissen → verwijderen vind ik goed, maar
> ‘enkel’ vind ik hier duidelijker.  Met wat slechte wil kan de ‘niet met
> iemand anders’-betekenis van ‘alleen’ voor verwarring zorgen.

Enkel klinkt oubollig/formeel, is wellicht wat Vlaams, en heeft in zo’n geval (zeker i.c.m. ‘gebeurtenis’) geen voorkeur. Zie ook vrttaal.net - taalkwesties.

> +<!ENTITY priority.level.none                "Niet gespecificeerd">
> Misschien ‘Niet opgegeven/aangegeven’?

Je zou kunnen weten dat dit in nagenoeg alle gevallen zo wordt vertaald. Het lijkt me niet de bedoeling dit hier anders te doen.

> -itemDeleteError=Er is een fout opgetreden bij het verwijderen van het item op
> de server.
> +itemDeleteError=Er is een fout opgetreden bij het verwijderen van het item van
> de server.

> Ha nee.  Het is toch op de server dat er iets misloopt.  Hier ook gebeurtenis
> voor item?

Ha ja. (?). Je verwijdert immers iets van de server, je slaat het op de server op. Het heeft dus niets met ‘een item op de server’ te maken, wat je ook aan het Engels had kunnen zien. Verder gaat het hier om een item, geen gebeurtenis.
 
> -<!ENTITY pref.calendar.advanced.encryption.certSelection.description "Wanneer
> een server mijn persoonlijk certificaat vraagt:">
> +<!ENTITY pref.calendar.advanced.encryption.certSelection.description "Wanneer
> een server om mijn persoonlijke certificaat verzoekt:">
> Hier zag ik toch liever het wat informelere ‘vragen’ behouden.

(Ook) een kwestie van consistentie, zoals aangegeven.

> -imipSendMailOutlook2000CompatMode=Outlook 2000 en Outlook 2002/XP
> ondersteunen.
> +imipSendMailOutlook2000CompatMode=Ondersteunen Outlook 2000 en Outlook
> 2002/XP.
> Dit ziet er wat raar uit, wat is de context?

Lijkt me niet. Waarom vraag je dat?

> Maar ik gebruik Lightning (jammer genoeg) nog niet echt, dus het kan goed zijn
> dat ik enkele use-cases over het hoofd zie.

Daarom misschien? Nogmaals een vriendelijk verzoek je beter te oriënteren en pas met kritiek te komen als je weet waar de zaken over gaan i.p.v. direct iets te roepen. Dit kost onnodig tijd en ik voel weinig behoefte om uitleg te geven als dat daardoor kan worden voorkomen. No offense.


    
    

    
  
(In reply to comment #168)
> (In reply to comment #164)
> > (In reply to comment #161)
> > De wijziging item → gebeurtenis en wissen → verwijderen vind ik goed, maar
> > ‘enkel’ vind ik hier duidelijker.  Met wat slechte wil kan de ‘niet met
> > iemand anders’-betekenis van ‘alleen’ voor verwarring zorgen.
> 
> Enkel klinkt oubollig/formeel, is wellicht wat Vlaams, en heeft in zo’n geval
> (zeker i.c.m. ‘gebeurtenis’) geen voorkeur. Zie ook vrttaal.net -
> taalkwesties.

Het zal dan wel weer Vlaams zijn, want ik vind het in dit geval dus duidelijker.

> > +<!ENTITY priority.level.none                "Niet gespecificeerd">
> > Misschien ‘Niet opgegeven/aangegeven’?
> 
> Je zou kunnen weten dat dit in nagenoeg alle gevallen zo wordt vertaald. Het
> lijkt me niet de bedoeling dit hier anders te doen.

Dan vind ik dat dit in nagenoeg alle gevallen door een minder formeel woord zou mogen vervangen worden.

> > -itemDeleteError=Er is een fout opgetreden bij het verwijderen van het item op
> > de server.
> > +itemDeleteError=Er is een fout opgetreden bij het verwijderen van het item van
> > de server.
> 
> > Ha nee.  Het is toch op de server dat er iets misloopt.  Hier ook gebeurtenis
> > voor item?
> 
> Ha ja. (?). Je verwijdert immers iets van de server, je slaat het op de server
> op. Het heeft dus niets met ‘een item op de server’ te maken, wat je ook
> aan het Engels had kunnen zien. Verder gaat het hier om een item, geen
> gebeurtenis.

Die discussie hadden we al eens geloof ik.  Er zijn argumenten voor beide.  Want het is toch de server die een foutmelding geeft dat het niet verwijderd kon worden.  Dus het item op de server kon niet verwijderd worden.  Maar alla, ik heb het toch al lang opgegeven over zulke dingen te discuteren.

> > -<!ENTITY pref.calendar.advanced.encryption.certSelection.description "Wanneer
> > een server mijn persoonlijk certificaat vraagt:">
> > +<!ENTITY pref.calendar.advanced.encryption.certSelection.description "Wanneer
> > een server om mijn persoonlijke certificaat verzoekt:">
> > Hier zag ik toch liever het wat informelere ‘vragen’ behouden.
> 
> (Ook) een kwestie van consistentie, zoals aangegeven.

Nu ja, je moet die consistentie toch niet te ver drijven.  Hier vind ik ‘verzoeken’ nodeloos formeel, terwijl dat op andere plaatsen gepast kan zijn.

> > -imipSendMailOutlook2000CompatMode=Outlook 2000 en Outlook 2002/XP
> > ondersteunen.
> > +imipSendMailOutlook2000CompatMode=Ondersteunen Outlook 2000 en Outlook
> > 2002/XP.
> > Dit ziet er wat raar uit, wat is de context?
> 
> Lijkt me niet. Waarom vraag je dat?

Omdat ik die string in zijn context wil zien, tiens.  Ik doe hier aan reviewen, dat wil zeggen: ik lees de patch, en laat weten wat me opvalt.  Dit is iets wat me opvalt.  Ik wil hiermee niet zeggen dat het slecht is of fout, maar vraag gewoon om wat hulp bij het evalueren van de wijzigingen.  Als dat te veel gevraagd is, dan moet je, vrees ik, je eisen wat bijstellen.

> > Maar ik gebruik Lightning (jammer genoeg) nog niet echt, dus het kan goed zijn
> > dat ik enkele use-cases over het hoofd zie.
> 
> Daarom misschien? Nogmaals een vriendelijk verzoek je beter te oriënteren en
> pas met kritiek te komen als je weet waar de zaken over gaan i.p.v. direct iets
> te roepen. Dit kost onnodig tijd en ik voel weinig behoefte om uitleg te geven
> als dat daardoor kan worden voorkomen. No offense.

Zoals gezegd, dit is geen kritiek, dit zijn opmerkingen.  In het belang van de algemeenheid.  Dit is mijn manier van werken.  Als je er niet mee om kan gaan, wel, negeer het dan, hopelijk zal iemand anders tenminste mijn opmerkingen lezen en er rekening mee houden.


    
    

    
  
Ton,

Als je geen peer review wilt en gewoon je eigen dingen wilt inchecken zonder dat iemand zich ermee bemoeit, moet je het maar zeggen hoor. Dan kan iedereen zijn tijd beter besteden.

    
    

    
  
> Ja ik had ook zojuist 0.9 geïnstalleerd om dat te checken, maar die is in het
> Engels en nu wil hij niet meer werken als ik 0.8 terug installeer :(. Zijn er
> Nederlandse nightlies?
Laurens, Wat gebruik je? Sunbird of Lightning? Van sunbird vind je de nightlies in volgende directory: http://ftp.mozilla.org/pub/mozilla.org/calendar/sunbird/nightly/latest-mozilla1.8-l10n/

(In reply to comment #163)
> (In reply to comment #161)
> Index: nl/calendar/chrome/calendar/calendar-occurrence-prompt.dtd
> 
> ....
> +<!ENTITY buttons.parent.accesskey "A">
> \ No newline at end of file <<---
> 
> Kun je hier nadien nog een newline toevoegen? (Een nieuwe patch is wellicht wat
> overdreven..)
> 
Dit zal ik doen als ik de patch toepas (dus als er eensgezindheid over alle vertalingen zijn...

> Enkel klinkt oubollig/formeel, is wellicht wat Vlaams, en heeft in zo’n geval
> (zeker i.c.m. ‘gebeurtenis’) geen voorkeur. Zie ook vrttaal.net -
> taalkwesties.
Ton, ik hoop dat je niet bedoelt dat Vlaams oubollig is?

> > +<!ENTITY priority.level.none                "Niet gespecificeerd">
> > Misschien ‘Niet opgegeven/aangegeven’?
> 
> Je zou kunnen weten dat dit in nagenoeg alle gevallen zo wordt vertaald. Het
> lijkt me niet de bedoeling dit hier anders te doen.
Dit is inderdaad zo, maar het Engels is ook afgestapt van 'Not specified' naar 'None' (minder formeel dus?)

en nog een laatste opmerking:
Ton, sorry van de timezones... Ik ben weggeroepen geweest in het midden van het bestand, en ben vergeten om het verder aan te passen... Aangezien de bovenkant Nederlands was, heb ik er verder over gelezen... mea culpa...




    
    

    
  
Comment on attachment 324603 [details] [diff] [review]
deïnst -> de-inst

Patch toegepast op branch en trunk.

        Attachment #324603 -
        Attachment is obsolete: true

    
    

    
  
Aanpassingen in trunk en 1.8_branch:

- chrome/calendar/calendar.properties  (dit is wel een deel van de patch, maar zo wordt de build opnieuw groen...)
- chrome/lightning/lightning.dtd


    
    

    
  
Hey iedereen:

Aangezien deze patch veel meer inhoudt dan waarover nog discussie is, zou ik hem graag inchecken en als we tot de conclusie komen dat er toch nog zaken opnieuw veranderd moeten worden, is dit geen probleem. 
Het is niet de bedoeling de discussie te stoppen met in te checken, maar vooral de vele accesskeys en enkele fouten van mijnentwege recht te zeggen...

De punten die ik er momenteel uithaal waarover nog discussie is, zijn de volgende:
> Enkel klinkt oubollig/formeel, is wellicht wat Vlaams, en heeft in zo’n geval
> (zeker i.c.m. ‘gebeurtenis’) geen voorkeur. Zie ook vrttaal.net -
> taalkwesties.

> > +<!ENTITY priority.level.none                "Niet gespecificeerd">
> > Misschien ‘Niet opgegeven/aangegeven’?
> 
> Je zou kunnen weten dat dit in nagenoeg alle gevallen zo wordt vertaald. Het
> lijkt me niet de bedoeling dit hier anders te doen.

> > -<!ENTITY pref.calendar.advanced.encryption.certSelection.description "Wanneer
> > een server mijn persoonlijk certificaat vraagt:">
> > +<!ENTITY pref.calendar.advanced.encryption.certSelection.description "Wanneer
> > een server om mijn persoonlijke certificaat verzoekt:">
> > Hier zag ik toch liever het wat informelere ‘vragen’ behouden.
> 
> (Ook) een kwestie van consistentie, zoals aangegeven.

> -imipSendMailOutlook2000CompatMode=Outlook 2000 en Outlook 2002/XP
> ondersteunen.
> +imipSendMailOutlook2000CompatMode=Ondersteunen Outlook 2000 en Outlook
> 2002/XP.
> Dit ziet er wat raar uit, wat is de context?


Wanneer alles ingechecked is, kunnen we ook nakijken wat de gevolgen zijn via de testversies.
Ik zal hierna proberen om een test-versie van Lightning te bouwen, zodat we ook hier alles kunnen controleren...

Kan iedereen zich hier in vinden?


    
    

    
  
(In reply to comment #169)

> Het zal dan wel weer Vlaams zijn, want ik vind het in dit geval dus
> duidelijker.

Ook dat, maar de genoemde bron moet toch al genoeg zeggen. Tik het voor de grap ook eens allebei in bij Google.
 
> Dan vind ik dat dit in nagenoeg alle gevallen door een minder formeel woord zou
> mogen vervangen worden.

Dat is een ander (en niet onverwacht) punt, maar ik vind het niet echt nodig en ook niet de moeite van het vermelden in een correctiepatch waard. 

> Die discussie hadden we al eens geloof ik.  Er zijn argumenten voor beide. 
> Want het is toch de server die een foutmelding geeft dat het niet verwijderd
> kon worden.  Dus het item op de server kon niet verwijderd worden.  Maar alla,
> ik heb het toch al lang opgegeven over zulke dingen te discuteren.

Die discussie heeft hier denk ik niets mee te maken. Wat hier staat is toch echt dat er een fout optrad bij het (van de server) verwijderen van iets, en niet anders - te controleren door de woordvolgorde te veranderen. Een kwestie van goed lezen vermoedelijk, en niet te snel concluderen dat een ander fout zit.

> Nu ja, je moet die consistentie toch niet te ver drijven.  Hier vind ik
> ‘verzoeken’ nodeloos formeel, terwijl dat op andere plaatsen gepast kan
> zijn.

Ik vind het niet geoorloofd om me/ons in Mozilla-vertalingen te laten betrappen op ingevoerde inconsistenties als deze. Uiteraard heb ik hier getwijfeld over welke kant de zin op moest gaan, maar om logische en historische redenen voor de Firefox-vorm gekozen. Iets anders kan altijd nog, al lijkt het me zoals gezegd niet nodig.

> Omdat ik die string in zijn context wil zien, tiens.  Ik doe hier aan reviewen,
> dat wil zeggen: ik lees de patch, en laat weten wat me opvalt.  Dit is iets wat
> me opvalt.  Ik wil hiermee niet zeggen dat het slecht is of fout, maar vraag
> gewoon om wat hulp bij het evalueren van de wijzigingen.  Als dat te veel
> gevraagd is, dan moet je, vrees ik, je eisen wat bijstellen.

Hmm.. dit, samen met de door Laurens verdedigde punten vind ik toch wel een bewijs dat je soms ietwat ongeïnteresseerd en belemmerend bezig kan zijn. Laat ik het zo zeggen: het lijkt er regelmatig op dat je (bewust of onbewust) de boel loopt te remmen door zonder enig denk- of controlewerk en soms zelfs op een puberale manier maar wat te roepen, en ik ervaar dat een beetje als vervelend. Zo zou ik bijvoorbeeld ook niet de werkplaats van een garagebedrijf binnenlopen om als duidelijke leek te vragen of het vervangen van de klepzittingen nu wel zo nodig is als ik niet weet waar ze voor dienen, laat staan dat ik om andere zal vragen. Als je bij het alleen lezen van patches om context vraagt en ook nog slechts je eigen taalgevoel raadpleegt ben je m.i. niet verstandig bezig. En als je Calendar al nauwelijks gebruikt....

> Zoals gezegd, dit is geen kritiek, dit zijn opmerkingen.  In het belang van de
> algemeenheid.  Dit is mijn manier van werken.  Als je er niet mee om kan gaan,
> wel, negeer het dan, hopelijk zal iemand anders tenminste mijn opmerkingen
> lezen en er rekening mee houden.

Dat eerste begrijp ik, maar misschien kun je je ook afvragen of die manier van werken wel de juiste is. Ik ervaar het (soms, niet altijd) als meer nadelig dan in het voordeel. Terechte kritiek is welkom, maar gedraag je als het kan wat professioneler door je iets meer te verdiepen en als het kan door wat minder Vlaams te denken (en te schrijven), of hou je er niet mee bezig. Het is soms alsof je jaagt op fouten die er niet zijn en als het kan meteen van de gelegenheid gebruikmaakt iets wat voorbij komt en naar jouw mening niet deugt of anders kan aan de kaak te stellen, wat de patch onnodig kan vertragen en in veel gevallen tot nodeloze discussie leidt. Dan liever zoiets in een aparte patch, of beter nog, als vraag/voorstel i.p.v. een reeds gemaakte patch. In feite doe je dat nu ook, maar het komt nu als belemmerend over en het kost me/ons onnodig tijd en energie. Hopelijk begrijp je dat, en is daarmee ook Laurens’ vraag beantwoord.


    
    

    
  
(In reply to comment #174)
> Hey iedereen:
> 
> Aangezien deze patch veel meer inhoudt dan waarover nog discussie is, zou ik
> hem graag inchecken en als we tot de conclusie komen dat er toch nog zaken
> opnieuw veranderd moeten worden, is dit geen probleem. 
> Het is niet de bedoeling de discussie te stoppen met in te checken, maar vooral
> de vele accesskeys en enkele fouten van mijnentwege recht te zeggen...

Goed idee.  Jij bent de beheerder, dus vind ik dat jij mag beslissen wat doorgevoerd wordt.  Het grootste deel van de patch is sowieso een goede zaak, en ik vind het ook niet erg dingen nog eens te verandern.  Het is een dynamisch proces.

    
    

    
  
(In reply to comment #175)
> (In reply to comment #169)
> 
> > Het zal dan wel weer Vlaams zijn, want ik vind het in dit geval dus
> > duidelijker.
> 
> Ook dat, maar de genoemde bron moet toch al genoeg zeggen. 

Inderdaad.  Schrijftalig en formeler.  Grappig dat ik hieronder dan net probeer dat te verminderen.  Tsja.  Nu, het gaat mij niet om dit specifieke woordje, maar veel meer daarom, dat ‘alleen’ een beetje tweeduidig is.

> Tik het voor de grap
> ook eens allebei in bij Google.

Dat zegt niks, want ‘alleen’ heeft ook nog andere betekenissen.

> > Dan vind ik dat dit in nagenoeg alle gevallen door een minder formeel woord zou
> > mogen vervangen worden.
> 
> Dat is een ander (en niet onverwacht) punt, maar ik vind het niet echt nodig 

Nodig misschien niet, maar misschien wenselijk?  Mijn drijfveer hier is dat ik de gebruiker niet te afstandelijk wil bejegenen.  Je mag computergebruikers (jammer genoeg) niet overschatten; het is dan ook belangrijk ze niet af te schrikken met moeilijke woorden.
Wat is jouw beweeggrond?

> ook niet de moeite van het vermelden in een correctiepatch waard.

Dat is dus weer de methodediscussie.  Vind ik wel.  Discussie is belangrijk, en hoeft niet als kritiek opgevat te worden.

> > Die discussie hadden we al eens geloof ik.  Er zijn argumenten voor beide. 
> > Want het is toch de server die een foutmelding geeft dat het niet verwijderd
> > kon worden.  Dus het item op de server kon niet verwijderd worden.  Maar alla,
> > ik heb het toch al lang opgegeven over zulke dingen te discuteren.
> 
> Die discussie heeft hier denk ik niets mee te maken. Wat hier staat is toch
> echt dat er een fout optrad bij het (van de server) verwijderen van iets, en
> niet anders - te controleren door de woordvolgorde te veranderen. Een kwestie
> van goed lezen vermoedelijk, en niet te snel concluderen dat een ander fout
> zit.

Ah, dat is dus het pijnpunt.  Ik wil helemaal niet ‘concluderen dat een ander fout zit’.  Ik probeer met gezond verstand je wijzigingen te overlopen om te vermijden dat er fouten in zitten.  Nu weet ik ondertussen wel dat jij zeer nauwgezet en betrouwbaar te werk gaat (hm, moet dit aan elkaar?), en dat ik dus niet op elk detail hoef te letten.  Zo controleer ik bv. helemaal niet op access keys, omdat ik weet dat jij dat goed onder controle hebt.  Maar ik lees ook mee op andere vertalersmailinglijsten, en daar is het vaak hard nodig in te grijpen (dingen als ‘History’ met ‘Historie’ vertalen, je kan het je soms niet voorstellen).  Deze voorzichtigheid wil ik ook hier niet helemaal laten varen.  Uiteindelijk is het dan de verantwoordelijk die kan beslissen wat er met patches gedaan wordt, maar het is natuurlijk mooi als door deze discussies betere resultaten bereikt worden.

> > Nu ja, je moet die consistentie toch niet te ver drijven.  Hier vind ik
> > ‘verzoeken’ nodeloos formeel, terwijl dat op andere plaatsen gepast kan
> > zijn.
> 
> Ik vind het niet geoorloofd om me/ons in Mozilla-vertalingen te laten betrappen
> op ingevoerde inconsistenties als deze. Uiteraard heb ik hier getwijfeld over
> welke kant de zin op moest gaan, maar om logische en historische redenen voor
> de Firefox-vorm gekozen. Iets anders kan altijd nog, al lijkt het me zoals
> gezegd niet nodig.
> 
> > Omdat ik die string in zijn context wil zien, tiens.  Ik doe hier aan reviewen,
> > dat wil zeggen: ik lees de patch, en laat weten wat me opvalt.  Dit is iets wat
> > me opvalt.  Ik wil hiermee niet zeggen dat het slecht is of fout, maar vraag
> > gewoon om wat hulp bij het evalueren van de wijzigingen.  Als dat te veel
> > gevraagd is, dan moet je, vrees ik, je eisen wat bijstellen.
> 
> Hmm.. dit, samen met de door Laurens verdedigde punten vind ik toch wel een
> bewijs dat je soms ietwat ongeïnteresseerd en belemmerend bezig kan zijn. Laat
> ik het zo zeggen: het lijkt er regelmatig op dat je (bewust of onbewust) de
> boel loopt te remmen door zonder enig denk- of controlewerk en soms zelfs op
> een puberale manier maar wat te roepen, en ik ervaar dat een beetje als
> vervelend. Zo zou ik bijvoorbeeld ook niet de werkplaats van een garagebedrijf
> binnenlopen om als duidelijke leek te vragen of het vervangen van de
> klepzittingen nu wel zo nodig is als ik niet weet waar ze voor dienen, laat
> staan dat ik om andere zal vragen. Als je bij het alleen lezen van patches om
> context vraagt en ook nog slechts je eigen taalgevoel raadpleegt ben je m.i.
> niet verstandig bezig. En als je Calendar al nauwelijks gebruikt....

Ik vind het jammer dat ik een verkeerde indruk op je maak.  Ik hoop dat ik hierboven een beetje heb kunnen uitleggen hoe ik hierbij denk.  Ik denk niet dat het nodig is om voor zoiets het programma goed te kennen en gebruiken.  Ik bestrijd niet dat dat beter zou zijn, maar je kan het gewoon niet verwachten.  Er zijn honderden programma’s die vertaald moeten worden, en bij lange na niet zoveel vrijwilligers.  Dus sommige programma’s moeten vertaald worden door mensen die ze niet actief gebruiken.  Goed, dat is hier dus gelukkig niet het geval.  Daarom zal je mij wijzigingen als deze ook zelden zien voorstellen.  Ik beperk me tot kleine dingen, waarvan ik zeker ben dat het geen verwarring zal opleveren.  Tenzij ik ook echt het programma gebruik en iets me opvalt, zoals onlangs bij de berichtenfilters van Thunderbird (ook een patch die er nog niet door is, maar dat is iets waar je aan went, als je eens patches hebt gemaakt die echt met code te doen hebben, daar kan het weken duren).

Laat het duidelijk zijn: ik probeer in geen geval de boel kunstmatig te remmen.  En ik stel je vergelijking op prijs, maar vind ze ietwat overdreven: zie bv. de access keys.

Het is ook niet per se zo dat je die context expliciet moet geven, maar dat ik er even op wil wijzen: hé, dit ziet er wat raar uit, ben je er wel zeker van.  Zoals reeds gezegd is dat bij jou meestal niet nodig, bij sommigen vaak genoeg.

> > Zoals gezegd, dit is geen kritiek, dit zijn opmerkingen.  In het belang van de
> > algemeenheid.  Dit is mijn manier van werken.  Als je er niet mee om kan gaan,
> > wel, negeer het dan, hopelijk zal iemand anders tenminste mijn opmerkingen
> > lezen en er rekening mee houden.
> 
> Dat eerste begrijp ik, maar misschien kun je je ook afvragen of die manier van
> werken wel de juiste is. Ik ervaar het (soms, niet altijd) als meer nadelig dan
> in het voordeel. Terechte kritiek is welkom, maar gedraag je als het kan wat
> professioneler door je iets meer te verdiepen en als het kan door wat minder
> Vlaams te denken (en te schrijven), of hou je er niet mee bezig. Het is soms
> alsof je jaagt op fouten die er niet zijn en als het kan meteen van de
> gelegenheid gebruikmaakt iets wat voorbij komt en naar jouw mening niet deugt
> of anders kan aan de kaak te stellen, wat de patch onnodig kan vertragen en in
> veel gevallen tot nodeloze discussie leidt. 

Dit is ook terechte kritiek, ik geef toe dat ik vaak wat snel ben met mijn opmerkingen.  Ik zal proberen om er wat langer over na te denken, maar je weet zelf ook dat het onbegonnen werk is alleen op basis van een string in een programma te gaan zoeken waar die nu opduikt.  Dat is echt te veel gevraagd.

Wat betreft dat Vlaams: ik doe mijn best hoor.  Zeker als ik zelf vertalingen bedenk probeer ik daar op te letten of tenminste voordien eens te vragen.  Maar het is natuurlijk gewoon zo dat zoiets jou veel sneller opvalt dan mij, omdat het voor mij niks bijzonders is…

> Dan liever zoiets in een aparte
> patch, of beter nog, als vraag/voorstel i.p.v. een reeds gemaakte patch. In
> feite doe je dat nu ook, maar het komt nu als belemmerend over en het kost
> me/ons onnodig tijd en energie. Hopelijk begrijp je dat, en is daarmee ook
> Laurens’ vraag beantwoord.

Dat vind ik een wat omslachtige werkwijze, maar er zit wel iets in.  Zoals ik in antwoord op Koen zei: een dynamisch proces.  Nu, ik ben benieuwd hoe dan op ‘tegenpatches’ gereageerd zal worden.  Het proberen waard.

    
    

    
  
Comment on attachment 327304 [details] [diff] [review]
Correcties en wijzigingen t/m 28/06

Toegepast op branch en trunk.

        Attachment #327304 -
        Attachment is obsolete: true

    
    

    
  
Aanpassing in 1.8_branch en trunk: 

chrome/calendar/calendar-occurrence-prompt.dtd (Bug 440550 - geen vertaling maar een xml code die ering geslopen was...)

    
    

    
  
Aanpassingen in branch en trunk:

chrome/calendar/calendar.dtd
chrome/calendar/calendar.properties
chrome/calendar/calendar.properties

    
    

    
  
Aanpassingen in branch en trunk:

chrome/calendar/calendar.dtd
chrome/calendar/calendar.properties
chrome/calendar/global.dtd


    
    

    
  

      
      
      
      

        Attached patch
          
          
        Aanpassingen t/m 12/07 (obsolete)
        — 
          — Splinter Review
      

    


  
Bevat kleine correctie op de wijzigingen van 10/07 en latere aanpassingen t/m vandaag.

Overigens voel ik veel voor omzetten van ‘ervoor’ naar ‘van tevoren’. Bezwaar?

    
    

    
  
Comment on attachment 329239 [details] [diff] [review]
Aanpassingen t/m 12/07

toegepast op branch en trunk.

        Attachment #329239 -
        Attachment is obsolete: true

    
    

    
  
Wat betreft je vraag van 'ervoor' te vervangen door 'van tevoren': Ik ben hier helemaal geen voorstander van. 
Dit komt voor bij de instelling van een herinnering: 5 minuten ervoor. 
5 minuten van tevoren klinkt, vind ik, niet goed in deze betekenis. Het heeft een rare bijbetekenis. (niet een herinnering, maar iets die 5 minuten langer duurt dat het andere.)

Trouwens, bedankt voor de patch.

    
    

    
  


  
Een aanpassing in twee zinnen die me al een tijdje dwarszaten omdat ze niet kloppen, en een klein vertaalfoutje.

    
    

    
  
(In reply to comment #184)
> 5 minuten van tevoren klinkt, vind ik, niet goed in deze betekenis. Het heeft
> een rare bijbetekenis. (niet een herinnering, maar iets die 5 minuten langer
> duurt dat het andere.)

Wat de bijbetekenis betreft, die zie ik totaal niet, misschien dat je dat kunt verklaren?

Doorgaans spreekt men over een waarschuwing die van tevoren plaatsvindt, in elk geval als hierbij een tijdsduur wordt genoemd. "3 dagen van tevoren" klinkt in zo’n geval beter dan "3 dagen ervoor" (lees: waarvoor?). M.a.w., men zegt niet gauw "de waarschuwing vindt 3 dagen ervoor plaats", maar eerder "... vindt 3 dagen van tevoren plaats". Of anders: wanneer wilt u worden gewaarschuwd? Antwoord: 3 dagen van tevoren. Bij het zoeken naar vergelijkbare agendaherinneringspagina’s op het web (o.a. van MS) vind je ‘van tevoren’ ook veelal zo terug, al dan niet in omschrijvingen. Daarbij komt natuurlijk nog dat het logisch is dat de waarschuwing ervoor plaatsvindt en niet erna, wat dit woord m.i. ook onaantrekkelijk maakt. Overdenk het nog eens zou ik zeggen.

Iets anders: ik voel er ook wel wat voor om ‘Aanwezigen’ te vervangen door ‘Genodigden’. Een logische vervanging lijkt me die geen uitleg behoeft, eerlijk gezegd (ook) een beetje afgekeken. Een geteste patch staat klaar. Bezwaar?



    
    

    
  

      
      
      
      

        Attached patch
          
          
        aanwezigen -> genodigden (obsolete)
        — 
          — Splinter Review
      

    


  
Gezien de naderende string freeze en nieuwe wijzigingen in 1 van de bestanden post ik deze toch maar vast.

Ter aanvulling op comment 186: ik zag dat je (Koen) zelf verantwoordelijk bent voor de omzetting van ‘eerder’ naar ‘ervoor’, om precies te zijn via een herstelpatch, rev. 1.6 d.d. 23-11-06 (comment 12). Dan vond ik ‘eerder’ nog net iets beter, maar ook daarvoor geldt de hierboven genoemde (on)logica. ;)

    
    

    
  
Hey ton,

Bedankt voor je patches; ik zal deze week je patches bekijken (en toepassen) 
Wat betreft de string freeze: dit is voor de code en nu hebben de localizers 2 weken om hun vertaling in orde te zetten... 
Deze week zal ik alle andere strings ook nog vertalen (nieuwe strings)... het zijn er een hele hoop...

Wat betreft eerder vs ervoor vs ...
Waarom het van eerder naar ervoor gegaan is, weet ik eerlijk gezegd niet meer. 
Ik heb eigenlijk tegen eerder ook niet echt iets, maar vind ervoor zeker niet slechter...

grz

    
    

    
  
Comment on attachment 329300 [details] [diff] [review]
Standaard tijd waarop.. -> voorafgaand aan

toegepast op branch en trunk

        Attachment #329300 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 329391 [details] [diff] [review]
aanwezigen -> genodigden

toegepast op branch en trunk.

    
    

    
  
Aanpassingen in branch en trunk:

chrome/prototypes/sun-calendar-event-dialog.properties
chrome/calendar/timezones.properties
chrome/calendar/calendar.properties
chrome/prototypes/sun-calendar-event-dialog.dtd
chrome/lightning/lightning.dtd
chrome/lightning/lightning.properties
chrome/calendar/calendar.dtd

Hiermee zouden alle tinderboxes opnieuw groen moeten zien (als ik me niet gemist heb natuurlijk ;-))

    
    

    
  
Comment on attachment 329391 [details] [diff] [review]
aanwezigen -> genodigden

Sorry, vergeten obsolete te zetten...

        Attachment #329391 -
        Attachment is obsolete: true

    
    

    
  
en er is nog een aanpassing binnengelopen: aangepast in branch en trunk
chrome/prototypes/sun-calendar-event-dialog.dtd

    
    

    
  


  
Tevens enkele aanpassingen zoals
Omschrijving->Beschrijving bij agendagebeurtenis (consistentie en gangbaarder bij agenda’s)
+‘op’ bij daggebeurtenissen, komma’s voor ‘keer’ en enkele dubbele/betere keys. Ook overal hoofdletters in ‘Venster Vandaag’ nadat Koen het wijselijk ook zo had toegevoegd.

Overigens lijkt er een bug te zijn die geen ‘derde’ (en hoger) pakt bij maandherhalingen. Tevens mis ik de organisator bij gebeurtenisannuleringen (per mail).

    
    

    
  
Comment on attachment 330410 [details] [diff] [review]
Correcties en wijzigingen t/m 19/07

patch toegepast op trunk en branch

        Attachment #330410 -
        Attachment is obsolete: true

    
    

    
  
Om maar even terug te komen op de discussie van eind vorig jaar…

Aangezien een ‘Agenda alarm’ tegenwoordig blijkbaar een ‘Herinnering’ heet (de venstertitel is ‘1 herinneringen’, wat overigens best enkelvoud zou mogen zijn), vind ik ook de nieuwe vertaling ‘Uitschakelen’ (ipv. ‘Afstellen’) niet goed. Een alarm uitschakelen klonk wel zinvol, maar een herinnering uitschakelen is toch weer vreemd.

Nieuwe suggestie: Verwijderen.

(Niet helemaal nieuw, want dit was ook al mijn oorspronkelijke suggestie in comment 63)

    
    

    
  
Hey,

Ik ben momenteel druk bezig in mijn huis aan het renoveren. Normaal verhuis ik eind deze maand. Dit heeft tot gevolg dat ik momenteel bijna geen tijd heb om vertalingen op te volgen, alsook dat ik begin december zal zonder internet zitten...

Indien dit een release zou kunnen verstoren, (ik ben momenteel niet echt mee wanneer de volgende release zou zijn, sorry) willen jullie dit dan eventjes voor zich nemen. Normaal zou ik tegen kerstdag opnieuw online zitten en zou alles als tevoren moeten verlopen...

Ik heb ook nog niet kunnen uitzoeken hoe HG werkt. Normaal zou dit tegen kerstdag moeten kunnen starten...

sorry voor deze laattijdige kennisgeving...
Alvast bedankt voor het begrip...

grz

    
    

    
  
Komt goed. Ik wilde eerdaags (na navraag bij jou) e.e.a. al gaan bijwerken.

    
    

    
  


  
Als het goed is trekt dit alles weer recht in hg.

(In reply to comment #196)
> 
> Aangezien een ‘Agenda alarm’ tegenwoordig blijkbaar een ‘Herinnering’ heet (de
> venstertitel is ‘1 herinneringen’, wat overigens best enkelvoud zou mogen
> zijn), vind ik ook de nieuwe vertaling ‘Uitschakelen’ (ipv. ‘Afstellen’) niet
> goed. Een alarm uitschakelen klonk wel zinvol, maar een herinnering
> uitschakelen is toch weer vreemd.
> 
> Nieuwe suggestie: Verwijderen.

Ik heb hier Verwijderen van gemaakt. Het enkelvoud heb ik zo gelaten (i.p.v. ‘herinnering(en)’), maar hiervoor is bug 466996 aangemaakt.

Ook hidexxx.commandkey zijn verwerkt (bug 461868).

(In reply to comment #142)
> 
> ‘Agendaeigenschappen’ is dus taalkundig juist (ae vormt geen klinkerbotsing),

Correctie op mezelf: ae vormt wel degelijk klinkerbotsing en (ook bij een samenstelling met drie klinkers) is er dus een streepje nodig.

    
    

    
  


  
Bevat de wijziging voor bug 466996.

        Attachment #350347 -
        Attachment is obsolete: true

    
    

    
  
Ik heb de patch eventjes nagelezen en heb eigenlijk maar 1 opmerking:

Wat betreft volgende punten:
384 <!ENTITY read.only.accept.label          "Ik zal aanwezig zijn">
385 <!ENTITY read.only.decline.label         "Ik zal niet aanwezig zijn">
386 <!ENTITY read.only.tentative.label       "Ik ben misschien aanwezig">
387 <!ENTITY read.only.needs.action.label    "Ik zal later bevestigen">
Moet 386 ook niet 'Ik zal misschien aanwezig zijn' zijn?'

Is er iemand (Tim maks?) die deze patch dan kan opladen... Ik kan wel mijn mail checken, en eventjes vrijmaken om dingen op te volgen, maar opladen zal me niet lukken tot eind december... Alvast bedankt.

    
    

    
  
(In reply to comment #201)

> Is er iemand (Tim maks?) die deze patch dan kan opladen...

doe ik vanavond/morgen

    
    

    
  
Comment on attachment 350423 [details] [diff] [review]
Aanpassingen na cvs -> hg t/m 26-11 v2

Patch toegepast

(In reply to comment #201)
> Ik heb de patch eventjes nagelezen en heb eigenlijk maar 1 opmerking:
> 
> Wat betreft volgende punten:
> 384 <!ENTITY read.only.accept.label          "Ik zal aanwezig zijn">
> 385 <!ENTITY read.only.decline.label         "Ik zal niet aanwezig zijn">
> 386 <!ENTITY read.only.tentative.label       "Ik ben misschien aanwezig">
> 387 <!ENTITY read.only.needs.action.label    "Ik zal later bevestigen">
> Moet 386 ook niet 'Ik zal misschien aanwezig zijn' zijn?'
> 

Als jullie een besluit hebben genomen, graag als een patch aanbieden

        Attachment #350423 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #201)
> 
> Moet 386 ook niet 'Ik zal misschien aanwezig zijn' zijn?'

Ik heb hier wel even getwijfeld maar toch bewust voor deze vorm gekozen, omdat ‘might’ wel vaker in de tegenwoordige tijd wordt vertaald als toch wel blijkt dat het om iets in de toekomst gaat (bv. ‘it might rain’ - ‘misschien regent het’ of ‘het kan misschien regenen’), en omdat ik het ook zo zag in een andere agendavertaling. Maar als meer mensen de voorkeur geven aan de genoemde vorm dan leg ik me daar bij neer.

    
    

    
  
(In reply to comment #200)
> Created an attachment (id=350423) [details]
> Aanpassingen na cvs -> hg t/m 26-11 v2
> 
> Bevat de wijziging voor bug 466996.

+<!ENTITY event.email.tentative.attendees.label            "E-mail opstellen aan onbesliste genodigden…">
‘onbeslist’ komt van ‘undecided’, waarmee hier echter bedoeld wordt: ‘die nog niet beslist hebben’.  Ik denk niet dat je ‘beslissen’ op die manier kan gebruiken in het Nederlands.  Voorstel: ‘onzeker’.

+<!ENTITY event.reminder.5minutes.before.label             "5 minuten ervoor" >
en de anderen: ervoor -> vooraf

+specifyLinkLocation=Specificeer de koppelingslocatie
Dit is juist, maar de laatste tijd ben ik het beter beginnen vinden ‘specify’ met ‘opgeven’ te vertalen.  Wat vinden anderen hiervan?  Dan zou het worden: ‘Geef de koppelingslocatie op’.

+summaryDueTaskLabel=Verval:
‘Due’ is moeilijk te vertalen, maar dit is denk ik niet duidelijk genoeg. Ik stel voor om er ‘Vervaldatum’ van te maken, dat geeft mijn Van Dale voor ‘due date’.

+imipSendMail.Outlook2000CompatMode.text=Ondersteunen Outlook 2000 en Outlook 2002/XP
Outlook 2000 en Outlook 2002/XP ondersteunen

+<!ENTITY copyrightText          "&#169;1998-2008 Medewerkers. Alle rechten
Laten we hier maar een echte © in zetten.

Blij te zien dat je (Ton) de vertalingen al goed genoeg vind om jezelf bij de credits op te nemen :-)

(In reply to comment #204)
> (In reply to comment #201)
> > 
> > Moet 386 ook niet 'Ik zal misschien aanwezig zijn' zijn?'
> 
> Ik heb hier wel even getwijfeld maar toch bewust voor deze vorm gekozen, omdat
> ‘might’ wel vaker in de tegenwoordige tijd wordt vertaald als toch wel blijkt
> dat het om iets in de toekomst gaat (bv. ‘it might rain’ - ‘misschien regent
> het’ of ‘het kan misschien regenen’), en omdat ik het ook zo zag in een andere
> agendavertaling. Maar als meer mensen de voorkeur geven aan de genoemde vorm
> dan leg ik me daar bij neer.

Grm, moeilijk inderdaad, maar voor de consistentie zou ik toch ook voor een versie met ‘zullen’ kiezen, te meer daar mensen die verschillende strings tegelijk zullen zien, geloof ik.

    
    

    
  


  
(In reply to comment #205)
> 
> +<!ENTITY event.email.tentative.attendees.label            "E-mail opstellen
> aan onbesliste genodigden…">
> ‘onbeslist’ komt van ‘undecided’, waarmee hier echter bedoeld wordt: ‘die nog
> niet beslist hebben’.  Ik denk niet dat je ‘beslissen’ op die manier kan
> gebruiken in het Nederlands.  Voorstel: ‘onzeker’.

Al langer een punt van aandacht, maar hoewel ik begrijp wat je bedoelt en er om deze reden ook over heb getwijfeld denk ik dat het toch wel kan. Wat bv. te denken van onbesliste kiezers? Een echt alternatief lijkt er ook niet te zijn; ‘die nog niet hebben gereageerd/besloten’ is een optie, maar wat lang en niet helemaal wat wordt bedoeld. ‘Onzeker’ vind ik geen alternatief, dit heeft immers niets met onzekere personen te maken, terwijl dit wel zo overkomt.

> +<!ENTITY event.reminder.5minutes.before.label             "5 minuten ervoor" >
> en de anderen: ervoor -> vooraf

Zelfstandig (of liever: zonder tekst erachter) wat formeel, mischien zelfs Vlaams. Dan voel ik meer voor het al eerder aangehaalde ‘van tevoren’, hetgeen ook bij MS wordt gebruikt en er in de keuzekolom goed uitziet, m.n. bij dagen. Dit zit in de patch.

> +specifyLinkLocation=Specificeer de koppelingslocatie
> Dit is juist, maar de laatste tijd ben ik het beter beginnen vinden ‘specify’
> met ‘opgeven’ te vertalen.  Wat vinden anderen hiervan?  Dan zou het worden:
> ‘Geef de koppelingslocatie op’.

Dit zie ik niet zo zitten; het lijkt niet echt nodig en in veel gevallen gaat dit ten koste van een goed lopende zin. Ook niet op enkele plaatsen, het komt ook wat als spreektaal over.

> +summaryDueTaskLabel=Verval:
> ‘Due’ is moeilijk te vertalen, maar dit is denk ik niet duidelijk genoeg. Ik
> stel voor om er ‘Vervaldatum’ van te maken, dat geeft mijn Van Dale voor ‘due
> date’.

Ook eerder besproken. Het ziet er naar uit dat hier met Due en Due date hetzelfde wordt bedoeld, dus wat dat betreft lijkt het wel te kunnen. Maar omdat we in alles met ‘verval’ het ‘verwachten’ c.q. de uiterlijke eindtijd niet terugzien terwijl dat wel wordt bedoeld (zie comment 94) en het misschien zelfs verwarring zou kunnen geven (het heeft immers niets met vervallen te maken) voel ik er meer voor hier Einddatum te gebruiken, net zoals Outlook dat doet. Sterker nog, het wordt elders geloof ik al einddatum genoemd dus lijkt het niet meer dan logisch, en evenzo kan ‘Due in’ maar beter ‘Einddatum over’ worden. Overigens schijnt Mac wel Vervaldatum te gebruiken, maar dat lijkt me geen reden het ook te doen.

> +imipSendMail.Outlook2000CompatMode.text=Ondersteunen Outlook 2000 en Outlook
> 2002/XP
> Outlook 2000 en Outlook 2002/XP ondersteunen

Dit heb je eerder zo voorgesteld, maar het verdient denk ik geen schoonheidsprijs. Ik neem aan dat je de context inmiddels hebt bekeken?. ‘Ondersteunen’ aan het einde van een optie zie ik niet zitten, vandaar nu vooraan, waardoor het op de ontvangers slaat. Beter is wellicht ‘Ondersteuning voor Outlook... inschakelen’, ‘Outlook 2000- en Outlook 2002/XP-compatibel’ of ‘Compatibel met Outlook 2000...’ (zie Fr), en in het laatste geval een voorstel voor en-US hiervoor. Deze zit ook in de patch.

> +<!ENTITY copyrightText          "&#169;1998-2008 Medewerkers. Alle rechten
> Laten we hier maar een echte © in zetten.

Liever eerst via en-US (of zorg voor een bug daarvoor als je wilt) maar omdat het bij TB ook al is gebeurd, OK.

> Blij te zien dat je (Ton) de vertalingen al goed genoeg vind om jezelf bij de
> credits op te nemen :-)

Dit stond eerst ergens anders en is geen eigen actie geweest.

> (In reply to comment #204)
> > (In reply to comment #201)
> > > 
> > > Moet 386 ook niet 'Ik zal misschien aanwezig zijn' zijn?'
> > 
> > Ik heb hier wel even getwijfeld maar toch bewust voor deze vorm gekozen, omdat
> > ‘might’ wel vaker in de tegenwoordige tijd wordt vertaald als toch wel blijkt
> > dat het om iets in de toekomst gaat (bv. ‘it might rain’ - ‘misschien regent
> > het’ of ‘het kan misschien regenen’), en omdat ik het ook zo zag in een andere
> > agendavertaling. Maar als meer mensen de voorkeur geven aan de genoemde vorm
> > dan leg ik me daar bij neer.
> 
> Grm, moeilijk inderdaad, maar voor de consistentie zou ik toch ook voor een
> versie met ‘zullen’ kiezen, te meer daar mensen die verschillende strings
> tegelijk zullen zien, geloof ik.

Niet getest maar ik dacht ook dat ze tegelijkertijd zichtbaar waren. Laten we deze maar wijzigen dan.

Verder in deze patch: wijzigingen van laatste dagen, vrije positie -> vrij tijdstip, toekomstige -> komende (nog niet gebruikt maar dan wel vast in orde, Koen weet hiervan) en enkele accesskeys terug waar ze vanwege bug 143065 waren weggelaten.

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

    
    

    
  
Comment on attachment 351708 [details] [diff] [review]
Aanpassingen t/m 06-12 en diversen

># HG changeset patch
># User Ton
># Date 1228593479 -3600
># Node ID ec38040533b32da663d8ba000b425e28760e457a
># Parent  065412eed76540b3396a2683e0dc5bcf8cfdb6a9
>Cal 20081206
>
>diff --git a/calendar/chrome/calendar/calendar-event-dialog.dtd b/calendar/chrome/calendar/calendar-event-dialog.dtd
>--- a/calendar/chrome/calendar/calendar-event-dialog.dtd
>+++ b/calendar/chrome/calendar/calendar-event-dialog.dtd
>@@ -214,18 +214,18 @@
> <!ENTITY event.priority2.label                            "Prioriteit:">
> 
> <!ENTITY event.reminder.none.label                        "Geen herinnering " >
>-<!ENTITY event.reminder.5minutes.before.label             "5 minuten ervoor" >
>-<!ENTITY event.reminder.10minutes.before.label            "10 minuten ervoor" >
>-<!ENTITY event.reminder.15minutes.before.label            "15 minuten ervoor" >
>-<!ENTITY event.reminder.30minutes.before.label            "30 minuten ervoor" >
>-<!ENTITY event.reminder.45minutes.before.label            "45 minuten ervoor" >
>-<!ENTITY event.reminder.1hour.before.label                "1 uur ervoor" >
>-<!ENTITY event.reminder.2hours.before.label               "2 uur ervoor" >
>-<!ENTITY event.reminder.5hours.before.label               "5 uur ervoor" >
>-<!ENTITY event.reminder.15hours.before.label              "15 uur ervoor" >
>-<!ENTITY event.reminder.1day.before.label                 "1 dag ervoor" >
>-<!ENTITY event.reminder.2days.before.label                "2 dagen ervoor" >
>-<!ENTITY event.reminder.1week.before.label                "1 week ervoor" >
>+<!ENTITY event.reminder.5minutes.before.label             "5 minuten van tevoren" >
>+<!ENTITY event.reminder.10minutes.before.label            "10 minuten van tevoren" >
>+<!ENTITY event.reminder.15minutes.before.label            "15 minuten van tevoren" >
>+<!ENTITY event.reminder.30minutes.before.label            "30 minuten van tevoren" >
>+<!ENTITY event.reminder.45minutes.before.label            "45 minuten van tevoren" >
>+<!ENTITY event.reminder.1hour.before.label                "1 uur van tevoren" >
>+<!ENTITY event.reminder.2hours.before.label               "2 uur van tevoren" >
>+<!ENTITY event.reminder.5hours.before.label               "5 uur van tevoren" >
>+<!ENTITY event.reminder.15hours.before.label              "15 uur van tevoren" >
>+<!ENTITY event.reminder.1day.before.label                 "1 dag van tevoren" >
>+<!ENTITY event.reminder.2days.before.label                "2 dagen van tevoren" >
>+<!ENTITY event.reminder.1week.before.label                "1 week van tevoren" >
> <!ENTITY event.reminder.custom.label                      "Aangepast…" >
> 
> <!ENTITY event.reminder.multiple.label                    "Meerdere herinneringen…" >
>@@ -360,9 +360,9 @@
> <!-- Attendees dialog -->
> <!ENTITY invite.title.label              "Genodigden uitnodigen">
> <!ENTITY event.organizer.label           "Organisator">
>-<!ENTITY event.freebusy.suggest.slot     "Vrije plaats voorstellen:">
>-<!ENTITY event.freebusy.next.slot        "Volgende vrije plaats " >
>-<!ENTITY event.freebusy.previous.slot    " Vorige vrije plaats" >
>+<!ENTITY event.freebusy.suggest.slot     "Vrij tijdstip voorstellen:">
>+<!ENTITY event.freebusy.next.slot        "Volgend vrij tijdstip " >
>+<!ENTITY event.freebusy.previous.slot    " Vorig vrij tijdstip" >
> <!ENTITY event.freebusy.zoom             "Zoomen:">
> <!ENTITY event.freebusy.plus             "Volgend uur" >
> <!ENTITY event.freebusy.minus            "Vorig uur" >
>@@ -383,7 +383,7 @@
> <!ENTITY read.only.reply.label           "Antwoord:">
> <!ENTITY read.only.accept.label          "Ik zal aanwezig zijn">
> <!ENTITY read.only.decline.label         "Ik zal niet aanwezig zijn">
>-<!ENTITY read.only.tentative.label       "Ik ben misschien aanwezig">
>+<!ENTITY read.only.tentative.label       "Ik zal misschien aanwezig zijn">
> <!ENTITY read.only.needs.action.label    "Ik zal later bevestigen">
> <!ENTITY read.only.reminder.label        "Herinnering:">
> <!ENTITY read.only.attendees.label       "Genodigden">
>diff --git a/calendar/chrome/calendar/calendar-event-dialog.properties b/calendar/chrome/calendar/calendar-event-dialog.properties
>--- a/calendar/chrome/calendar/calendar-event-dialog.properties
>+++ b/calendar/chrome/calendar/calendar-event-dialog.properties
>@@ -130,7 +130,7 @@
> specifyLinkLocation=Specificeer de koppelingslocatie
> enterLinkLocation=Voer een webpagina- of documentlocatie in.
> 
>-summaryDueTaskLabel=Verval:
>+summaryDueTaskLabel=Einde:
> 
> # Attach File Dialog
> selectAFile=Selecteer de bestanden om te koppelen
>diff --git a/calendar/chrome/calendar/calendar.dtd b/calendar/chrome/calendar/calendar.dtd
>--- a/calendar/chrome/calendar/calendar.dtd
>+++ b/calendar/chrome/calendar/calendar.dtd
>@@ -77,13 +77,13 @@
> <!ENTITY calendar.unifinder.tree.percentcomplete.label "&#37; voltooid">
> <!ENTITY calendar.unifinder.tree.startdate.label     "Begin">
> <!ENTITY calendar.unifinder.tree.enddate.label       "Einde">
>-<!ENTITY calendar.unifinder.tree.duedate.label       "Verval">
>+<!ENTITY calendar.unifinder.tree.duedate.label       "Einddatum">
> <!ENTITY calendar.unifinder.tree.completeddate.label "Voltooid">
> <!ENTITY calendar.unifinder.tree.categories.label    "Categorie">
> <!ENTITY calendar.unifinder.tree.location.label      "Locatie">
> <!ENTITY calendar.unifinder.tree.status.label        "Status">
> <!ENTITY calendar.unifinder.tree.calendarname.label  "Agendanaam">
>-<!ENTITY calendar.unifinder.tree.duration.label      "Vervalt na">
>+<!ENTITY calendar.unifinder.tree.duration.label      "Einddatum over">
> <!ENTITY calendar.unifinder.close.tooltip            "Gebeurtenissen zoeken en gebeurtenissenlijst sluiten">
> 
> <!ENTITY calendar.today.button.tooltip            "Naar vandaag gaan" >
>@@ -194,10 +194,10 @@
> <!ENTITY calendar.context.deletethisevent.accesskey   "D">
> <!ENTITY calendar.context.deletecompleteseries.label  "Volledige reeks">
> <!ENTITY calendar.context.deletecompleteseries.accesskey   "r">
>-<!ENTITY calendar.context.deletefutureevents.label     "Alle toekomstige gebeurtenissen">
>-<!ENTITY calendar.context.deletefutureevents.accesskey "t">
>-<!ENTITY calendar.context.deletefuturetasks.label     "Alle toekomstige taken">
>-<!ENTITY calendar.context.deletefuturetasks.accesskey "t">
>+<!ENTITY calendar.context.deletefutureevents.label     "Alle komende gebeurtenissen">
>+<!ENTITY calendar.context.deletefutureevents.accesskey "m">
>+<!ENTITY calendar.context.deletefuturetasks.label     "Alle komende taken">
>+<!ENTITY calendar.context.deletefuturetasks.accesskey "m">
> <!ENTITY calendar.context.cutevent.label              "Knippen">
> <!ENTITY calendar.context.cutevent.accesskey          "n">
> <!ENTITY calendar.context.copyevent.label             "Kopiëren">
>diff --git a/calendar/chrome/calendar/calendar.properties b/calendar/chrome/calendar/calendar.properties
>--- a/calendar/chrome/calendar/calendar.properties
>+++ b/calendar/chrome/calendar/calendar.properties
>@@ -168,7 +168,7 @@
> # task/todo fields
> # start date time, due date time, task priority number, completed date time
> tooltipStart    =Begin:
>-tooltipDue      =Verval:
>+tooltipDue      =Einde:
> tooltipPriority =Prioriteit:
> tooltipPercent  =% voltooid:
> tooltipCompleted=Voltooid:
>@@ -466,10 +466,10 @@
> #    %2$S will be replaced with the name of the timezone
> datetimeWithTimezone=%1$S, %2$S
> 
>-# LOCALIZATION NOTE (longCalendarWeek):
>+# LOCALIZATION NOTE (singleLongCalendarWeek):
> # used for display of calendar weeks in short form like 'Calendar Week 43'
> #    %1$S will be replaced with the index of the week
>-longCalendarWeek=Kalenderweek: %1$S
>+singleLongCalendarWeek=Kalenderweek: %1$S
> 
> # LOCALIZATION NOTE (severalLongCalendarWeeks):
> # used for display of calendar weeks in short form like 'Calendar Weeks 43 - 45'
>@@ -477,10 +477,10 @@
> #    %2$S will be replaced with the index of the end-week
> severalLongCalendarWeeks=Kalenderweken %1$S-%2$S
> 
>-# LOCALIZATION NOTE (shortCalendarWeek):
>+# LOCALIZATION NOTE (singleShortCalendarWeek):
> # used for display of calendar weeks in short form like 'CW 43'
> #    %1$S will be replaced with the index of the week
>-shortCalendarWeek=KW: %1$S
>+singleShortCalendarWeek=KW: %1$S
> 
> # LOCALIZATION NOTE (severalShortCalendarWeeks):
> # used for display of calendar weeks in short form like 'CWs 43 - 45'
>diff --git a/calendar/chrome/calendar/preferences/alarms.dtd b/calendar/chrome/calendar/preferences/alarms.dtd
>--- a/calendar/chrome/calendar/preferences/alarms.dtd
>+++ b/calendar/chrome/calendar/preferences/alarms.dtd
>@@ -42,15 +42,15 @@
> 
> <!ENTITY pref.alarmgoesoff.label "Als een alarm afgaat:">
> <!ENTITY pref.playasound "Een geluid afspelen">
>-<!ENTITY pref.calendar.alarms.playsound.accessKey "p">
>+<!ENTITY pref.calendar.alarms.playsound.accessKey "u">
> <!ENTITY pref.calendar.alarms.sound.useDefault.label "Standaardgeluid gebruiken">
>-<!ENTITY pref.calendar.alarms.sound.useDefault.accessKey "">
>+<!ENTITY pref.calendar.alarms.sound.useDefault.accessKey "S">
> <!ENTITY pref.calendar.alarms.sound.browse.label "Bladeren…">
>-<!ENTITY pref.calendar.alarms.sound.browse.accessKey "">
>+<!ENTITY pref.calendar.alarms.sound.browse.accessKey "B">
> <!ENTITY pref.calendar.alarms.sound.preview.label "Voorbeeld">
>-<!ENTITY pref.calendar.alarms.sound.preview.accessKey "">
>+<!ENTITY pref.calendar.alarms.sound.preview.accessKey "V">
> <!ENTITY pref.showalarmbox "Een alarmvenster tonen">
>-<!ENTITY pref.calendar.alarms.showAlarmBox.accessKey "t">
>+<!ENTITY pref.calendar.alarms.showAlarmBox.accessKey "a">
> <!ENTITY pref.missedalarms "Gemiste alarmen tonen">
> <!ENTITY pref.calendar.alarms.missedAlarms.accessKey "G">
> <!ENTITY pref.calendar.alarms.defaults.label "Standaard alarminstellingen">
>diff --git a/calendar/chrome/calendar/preferences/categories.dtd b/calendar/chrome/calendar/preferences/categories.dtd
>--- a/calendar/chrome/calendar/preferences/categories.dtd
>+++ b/calendar/chrome/calendar/preferences/categories.dtd
>@@ -42,12 +42,12 @@
> 
> <!ENTITY pref.categories.add.title "Categorie toevoegen">
> <!ENTITY pref.categories.addButton.label "Toevoegen…">
>-<!ENTITY pref.categories.addButton.accesskey "">
>+<!ENTITY pref.categories.addButton.accesskey "T">
> <!ENTITY pref.categories.edit.title "Categorie bewerken">
> <!ENTITY pref.categories.editButton.label "Bewerken…">
>-<!ENTITY pref.categories.editButton.accesskey "">
>+<!ENTITY pref.categories.editButton.accesskey "B">
> <!ENTITY pref.categories.removeButton.label "Verwijderen">
>-<!ENTITY pref.categories.removeButton.accesskey "">
>+<!ENTITY pref.categories.removeButton.accesskey "V">
> <!ENTITY pref.categories.name.label "Naam">
> <!ENTITY pref.categories.color.label "Kleur">
> <!ENTITY pref.categories.usecolor.label "Kleur gebruiken">
>diff --git a/calendar/chrome/calendar/preferences/views.dtd b/calendar/chrome/calendar/preferences/views.dtd
>--- a/calendar/chrome/calendar/preferences/views.dtd
>+++ b/calendar/chrome/calendar/preferences/views.dtd
>@@ -58,11 +58,11 @@
> <!ENTITY pref.calendar.view.dayend.label "Dag eindigt om:">
> <!ENTITY pref.calendar.view.dayend.accesskey "i">
> <!ENTITY pref.calendar.view.visiblehours.label "Tonen:">
>-<!ENTITY pref.calendar.view.visiblehours.accesskey "n">
>+<!ENTITY pref.calendar.view.visiblehours.accesskey "T">
> <!ENTITY pref.calendar.view.visiblehoursend.label "uren per overzicht">
> 
>-<!ENTITY pref.numberofweeks.label "Standaard aantal weken (voorgaande weken inbegrepen):">
>-<!ENTITY pref.numberofweeks.accesskey "S">
>+<!ENTITY pref.numberofweeks.label "Aantal weken (voorgaande weken inbegrepen):">
>+<!ENTITY pref.numberofweeks.accesskey "n">
> <!ENTITY pref.numberofpreviousweeks.label "Aantal voorgaande weken:">
> <!ENTITY pref.numberofpreviousweeks.accesskey "r">
> <!ENTITY pref.numberofweeks.0 "geen">
>diff --git a/calendar/chrome/lightning/lightning.properties b/calendar/chrome/lightning/lightning.properties
>--- a/calendar/chrome/lightning/lightning.properties
>+++ b/calendar/chrome/lightning/lightning.properties
>@@ -78,7 +78,7 @@
> imipSend.label=Verzenden
> imipSendMail.title=E-mailnotificatie
> imipSendMail.text=Wilt u nu notificatie-e-mail versturen?
>-imipSendMail.Outlook2000CompatMode.text=Ondersteunen Outlook 2000 en Outlook 2002/XP
>+imipSendMail.Outlook2000CompatMode.text=Compatibel met Outlook 2000 en Outlook 2002/XP
> imipNoIdentity=Geen
> 
> itipReplySubject=Antwoord voor de gebeurtenisuitnodiging: %1$S
>diff --git a/calendar/chrome/sunbird/aboutDialog.dtd b/calendar/chrome/sunbird/aboutDialog.dtd
>--- a/calendar/chrome/sunbird/aboutDialog.dtd
>+++ b/calendar/chrome/sunbird/aboutDialog.dtd
>@@ -42,7 +42,7 @@
> <!ENTITY aboutLink.label        "&lt; Over &brandFullName;">
> <!ENTITY aboutLink.accesskey    "O">
> <!ENTITY aboutVersion           "versie">
>-<!ENTITY copyrightText          "&#169;1998-2008 Medewerkers. Alle rechten
>+<!ENTITY copyrightText          "© 1998-2008 Medewerkers. Alle rechten
>                                  voorbehouden. Mozilla Sunbird, Sunbird en de
>                                  Sunbird-logo’s zijn handelsmerken van de Mozilla
>                                  Foundation. Alle rechten voorbehouden.">
>diff --git a/calendar/chrome/sunbird/sunbird.dtd b/calendar/chrome/sunbird/sunbird.dtd
>--- a/calendar/chrome/sunbird/sunbird.dtd
>+++ b/calendar/chrome/sunbird/sunbird.dtd
>@@ -69,6 +69,7 @@
> 
> <!ENTITY sunbird.menu.numberofweeks.label                  "Aantal weken" >
> <!ENTITY sunbird.menu.numberofweeks.accesskey              "A" >
>+<!ENTITY sunbird.menu.numberofweeks.1                      "1 week" >
> <!ENTITY sunbird.menu.numberofweeks.2                      "2 weken" >
> <!ENTITY sunbird.menu.numberofweeks.3                      "3 weken" >
> <!ENTITY sunbird.menu.numberofweeks.4                      "4 weken" >

    
    

    
  
Hey,

Nog wat commentaar over de discussiepunten:

(In reply to comment #206)
> > +<!ENTITY event.reminder.5minutes.before.label             "5 minuten ervoor" >
> > en de anderen: ervoor -> vooraf
> 
> Zelfstandig (of liever: zonder tekst erachter) wat formeel, mischien zelfs
> Vlaams. Dan voel ik meer voor het al eerder aangehaalde ‘van tevoren’, hetgeen
> ook bij MS wordt gebruikt en er in de keuzekolom goed uitziet, m.n. bij dagen.
> Dit zit in de patch.

Vind ‘vooraf’ en ‘van tevoren’ beiden ok.

> > +specifyLinkLocation=Specificeer de koppelingslocatie
> > Dit is juist, maar de laatste tijd ben ik het beter beginnen vinden ‘specify’
> > met ‘opgeven’ te vertalen.  Wat vinden anderen hiervan?  Dan zou het worden:
> > ‘Geef de koppelingslocatie op’.
> 
> Dit zie ik niet zo zitten; het lijkt niet echt nodig en in veel gevallen gaat
> dit ten koste van een goed lopende zin. Ook niet op enkele plaatsen, het komt
> ook wat als spreektaal over.

Moet zeggen dat ik ‘specificeer’ ook niet echt mooi vind, het is een woord wat je in alledaags taalgebruik zelden zou gebruiken. Maar omdat het alleen maar als titel van een dialoogvenster wordt gebruikt en de dialoogvenster zelf alsnog aangeeft wat het verwacht kan het er hier wel mee door, I guess. Maar zeker als het een op zich zelf staande tekst is vind ik algemeen gesproken ‘opgeven’ (of iig iets anders dan ‘specificeer’) beter.

> -shortCalendarWeek=KW: %1$S
> +singleShortCalendarWeek=KW: %1$S

Ik zag ze overigens laatst in het NOS journaal ook ‘kw’ gebruiken. Wel in kleine letters.

Verder prima wijzigingen :).

    
  

        Attachment #351708 -
        Flags: review?(koen.hendrickx) → review+

    
    

    
  
Comment on attachment 351708 [details] [diff] [review]
Aanpassingen t/m 06-12 en diversen

toegepast op 1.9.1 en central

        Attachment #351708 -
        Attachment is obsolete: true

    
    

    
  


  

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

    
  

        Attachment #353270 -
        Flags: review?(koen.hendrickx) → review+

    
    

    
  
Comment on attachment 353270 [details] [diff] [review]
Aanpassingen t/m 16-12 en Mac-specifiek

toegepast op 1.9.1 en central

        Attachment #353270 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Aanpassingen van gisteren (obsolete)
        — 
          — Splinter Review
      

    


  

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

    
  

        Attachment #353714 -
        Flags: review?(koen.hendrickx) → review+

    
    

    
  
Comment on attachment 353714 [details] [diff] [review]
Aanpassingen van gisteren

toegepast op 1.9.1 en central

        Attachment #353714 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Aanpassingen van 19-12 (obsolete)
        — 
          — Splinter Review
      

    


  

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

    
  

        Attachment #353985 -
        Flags: review?(koen.hendrickx) → review+

    
    

    
  
Comment on attachment 353985 [details] [diff] [review]
Aanpassingen van 19-12

toegepast op 1.9.1 en central

        Attachment #353985 -
        Attachment is obsolete: true

    
    

    
  


  

    
  

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

    
    

    
  
Comment on attachment 354548 [details] [diff] [review]
2 ontbrekende strings van dit moment

Alvast bedankt voor dit te onderhouden... 
Mijn internetaansluiting is pas gepland op 15 januari... Ze werken hier niet echt vlug in België...

        Attachment #354548 -
        Flags: review?(koen.hendrickx) → review+

    
    

    
  
Comment on attachment 354548 [details] [diff] [review]
2 ontbrekende strings van dit moment

togepast op 1.9.1 en central

        Attachment #354548 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Recente wijziging + correctie (obsolete)
        — 
          — Splinter Review
      

    


  

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

    
  

        Attachment #356317 -
        Flags: review?(koen.hendrickx) → review+

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Wijziging van eergisteren (obsolete)
        — 
          — Splinter Review
      

    


  

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

    
    

    
  
Comment on attachment 356317 [details] [diff] [review]
Recente wijziging + correctie

toegepast op 1.9.1 en central

        Attachment #356317 -
        Attachment is obsolete: true

    
    

    
  


  

        Attachment #356976 -
        Attachment is obsolete: true

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

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

    
  

        Attachment #358646 -
        Flags: review?(koen.hendrickx) → review+

    
    

    
  
Hey iedereen,
Ik ben intussen verhuisd en heb ook opnieuw internet in huis... Alleen valt het me momenteel nog steeds héél zwaar om tijd vrij te maken om HG verder uit te zoeken, om alles gewoon bij te houden, ...
Er is niet alleen mijn huis waar nog steeds veel tijd inkruipt, maar ook de combinatie met werk verloopt veel minder vlot dan ik me had kunnen voorstellen. 

Dit als inleiding tot mijn vraag: Is er iemand die de vertaling van de agenda wil overnemen of laten we dit overgaan in de vertaling van thunderbird? (aangezien deze gaan gekoppeld worden.) 

Dit wil niet zeggen dat ik het project zo maar zal laten vallen, maar dat beetje extra tijd is moeilijk en met de vooruitzichten om het werk vermoed ik dat het binnen een half jaartje bijna onmogelijk zal worden. Ik laat het liever op voorhand weten dan op een moment het project voor voldongen feiten te stellen...

Alvast bedankt voor het begrip.

    
    

    
  
(In reply to comment #223)
> Dit als inleiding tot mijn vraag: Is er iemand die de vertaling van de agenda
> wil overnemen of laten we dit overgaan in de vertaling van thunderbird?
> (aangezien deze gaan gekoppeld worden.) 

Bedankt voor de info. Ik heb begrepen dat Calendar inderdaad onderdeel zal gaan uitmaken van TB, en dus als zodanig hierin kan worden meegenomen. Navraag leverde op dat we (volgens Simon) zelf kunnen beslissen of er een aparte vertaler voor nodig blijft, ofwel dat de bestaande TB-vertaler de Calendar-strings kan meenemen als hij daartoe bereid is. Tim moet daar dus maar even antwoord op geven denk ik. Als hij het Calendar-deel toch liever gescheiden wil houden ben ik wel bereid dit (al dan niet tijdelijk) over te nemen.

    
    

    
  
Comment on attachment 358646 [details] [diff] [review]
Wijzigingen van 24-01 incl. de vorige

toegepast op 1.9.1 en central

        Attachment #358646 -
        Attachment is obsolete: true

    
    

    
  
(In reply to comment #223)

> Dit als inleiding tot mijn vraag: Is er iemand die de vertaling van de agenda
> wil overnemen of laten we dit overgaan in de vertaling van thunderbird?
> (aangezien deze gaan gekoppeld worden.) 
> 
> Dit wil niet zeggen dat ik het project zo maar zal laten vallen, maar dat
> beetje extra tijd is moeilijk en met de vooruitzichten om het werk vermoed ik
> dat het binnen een half jaartje bijna onmogelijk zal worden. Ik laat het liever
> op voorhand weten dan op een moment het project voor voldongen feiten te
> stellen...
> 
> Alvast bedankt voor het begrip.

Alle begrip!! Ik wil je danken voor je inzet! hoe nu verder wil ik even bespreken met div mensen, het aanbod van Tonnes neem ik natuurlijk mee in de overweging.

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Aanpassingen t/m 06-02 (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 360992 [details] [diff] [review]
Aanpassingen t/m 06-02

toegepast op 1.9.1 en central

p.s. Tonnes ik hoop je snel te spreken op IRC over Calendar/Sunbird

        Attachment #360992 -
        Attachment is obsolete: true

    
    

    
  
Koen,

Ton gaat het beheer van calendar overnemen, ik dank je voor je inzet en ik hoop dat we nog patches/opmerkingen van je blijven krijgen.

Groet

Tim Maks
Assignee: koen.hendrickx → tonnes.mb

    
    

    
  
Hey,

Ik zal het zowiso nog proberen blijven op te volgen, gewoon omdat ik het project nog steeds wil blijven steunen. 

Bedankt Ton om het over te nemen.

Wat moet er eigenlijk met mijn login voor de Mozilla-server gebeuren?

grz,
Koen

    
    

    
  
(In reply to comment #230)

> 
> Wat moet er eigenlijk met mijn login voor de Mozilla-server gebeuren?
> 
> grz,
> Koen

wat mij betreft hou je die, dan kan je eventueel als peer optreden als Ton  verhindert is en er iets belangrijks met calendar moet gebeuren (als je dat tenminste wilt)

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Aanpassingen t/m 27-02 (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 364592 [details] [diff] [review]
Aanpassingen t/m 27-02

toegepastop 1.9.1 en central

        Attachment #364592 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Aanpassingen t/m 21-03 (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 368773 [details] [diff] [review]
Aanpassingen t/m 21-03

toegepast op 1.9.1 en central

        Attachment #368773 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Aanpassingen t/m 29-05 (obsolete)
        — 
          — Splinter Review
      

    


  

        Attachment #380481 -
        Attachment is obsolete: true

    
    

    
  
Comment on attachment 380481 [details] [diff] [review]
Aanpassingen t/m 29-05

toegepast

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Aanpassingen t/m 21-06 (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 384303 [details] [diff] [review]
Aanpassingen t/m 21-06

toegepast op 1.9.1 en central

        Attachment #384303 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Aanpassingen t/m 26-06 +keys (obsolete)
        — 
          — Splinter Review
      

    


  

    
    

    
  
Comment on attachment 385555 [details] [diff] [review]
Aanpassingen t/m 26-06 +keys

toegepast op 1.9.1 en central

        Attachment #385555 -
        Attachment is obsolete: true

    
    

    
  

      
      
      
      

        Attached patch
          
          
        Edits voor 1.0b2 (comm-1.9.2) (obsolete)
        — 
          — Splinter Review
      

    


  
Grondige controle van werking en keys is nog nodig (er is op dit moment geen win32-build beschikbaar).

    
    

    
  
Comment on attachment 444307 [details] [diff] [review]
Edits voor 1.0b2 (comm-1.9.2)

toegepast op central en 1.9.2

        Attachment #444307 -
        Attachment is obsolete: true

    
    

    
  


  
Was ‘addremove’ vergeten…

    
    

    
  
Comment on attachment 444320 [details] [diff] [review]
Edits voor 1.0b2 (comm-1.9.2) deel 2

Dat vermoeden had ik al, toegepast

        Attachment #444320 -
        Attachment is obsolete: true

    
    

    
  
Kan ik Lightning 1.0 Beta 2 vrijgeven?

    
    

    
  
Het kan, maar misschien moeten we nog maar even wachten? Er is immers nog even de tijd, en er kan dan wat beter worden getest i.c.m. TB 3.1pre nl.

    
    

    
  
(In reply to comment #247)
> Het kan, maar misschien moeten we nog maar even wachten? Er is immers nog even
> de tijd, en er kan dan wat beter worden getest i.c.m. TB 3.1pre nl.

Ik doe een sign-off, dan gaat hij in ieder geval mee met een officiële build. Als je nog iet wilt aanpassen kan dat altijd nog en doe ik een nieuwe sign-off. Dat is het voordeel van het nieuwe systeem, er wordt altijd met de laatste sign-off gewerkt.

    
    

    
  
Ton kijk eens hiernaar https://bugzilla.mozilla.org/show_bug.cgi?id=500397#c12, wellicht moeten wij die acceskey ook hetzelfde houden

    
    

    
  
windows vista met thunderbird 3.1 en laatste nightly van de nederlandse lightning:

Alle menu's etc zien er goed uit, ik heb zosnel geen probleem kunnen ontdekken.

    
    

    
  
(In reply to comment #249)
> Ton kijk eens hiernaar https://bugzilla.mozilla.org/show_bug.cgi?id=500397#c12,
> wellicht moeten wij die acceskey ook hetzelfde houden

Ik had de bug gezien, maar dat probleem geldt alleen in en-US. Het gebruik van de oude F (van File) in het Engels is een tijdelijke noodoplossing, omdat daar gewoonweg geen andere keuze voor een keyis. In de nl-versie kunnen we wel 2 eigen keys gebruiken, dus dat zou ik gewoon doen. Waarschijnlijk volgt en-US later alsnog als er keys vrijkomen.

(In reply to comment #250)
> windows vista met thunderbird 3.1 en laatste nightly van de nederlandse
> lightning:
> 
> Alle menu's etc zien er goed uit, ik heb zosnel geen probleem kunnen ontdekken.

Mooi… Ik schrok nog even vanwege een weergaveprobleem in het berichtvenster, maar dat lag waarschijnlijk aan bug 530047 en is sinds de laatste nightly verdwenen.

    
    

    
  
(In reply to comment #251)
> (In reply to comment #249)
> > Ton kijk eens hiernaar https://bugzilla.mozilla.org/show_bug.cgi?id=500397#c12,
> > wellicht moeten wij die acceskey ook hetzelfde houden
> 
> Ik had de bug gezien, maar dat probleem geldt alleen in en-US. Het gebruik van
> de oude F (van File) in het Engels is een tijdelijke noodoplossing, omdat daar
> gewoonweg geen andere keuze voor een keyis. In de nl-versie kunnen we wel 2
> eigen keys gebruiken, dus dat zou ik gewoon doen. Waarschijnlijk volgt en-US
> later alsnog als er keys vrijkomen.
> 

You could revert to the previously used Alt+F to keep keyboard compatibility to
previous releases and to keep the same shortcuts in event and task layout.

hier kan je ook uit opmaken dat omdat er geen goede key is ze kiezen voor backward compatibility en ik doelde daarop, ondanks dat het in nl wel mogelijk is.

    
    

    
  
Sign offs are now open for Lightning 1.0b4.

These will be open until June 7th @ 23:59 PDT.

Note there will be no pre-release like with Thunderbird, if you need
to test your localization please use the nightly l10n builds provided.

Your signoffs are available here:

https://l10n-stage-sj.mozilla.org/shipping/dashboard?av=calendar1.0

    
    

    
  
Hello Folks,

Lightning now turning 1.0, we would like to mark the cache as no longer experimental. Unfortunately we are very late in the cycle and have taken great care not to change any strings since the last release.

To not burden you with additional string changes for the 1.0 release, we have chosen to make the following string change optional. We would be delighted if you have a minute to remove the "Experimental" label from the string, but won't drop your locale if its not translated.

You can see the string change here:
http://hg.mozilla.org/releases/comm-beta/rev/09bcb1cd1240

When you are done, please request sign-off on calendar10x.

Thanks,
Philipp

    
    

    
  
(In reply to Ton from comment #256)
> Done:
> http://hg.mozilla.org/releases/l10n-miramar/nl//rev/ce8c84aa74b0

wil deze patch ook toepassen op central en aurora?

    
    

    
  
(In reply to Tim Maks van den Broek from comment #257)
> 
> wil deze patch ook toepassen op central en aurora?

Yup…

http://hg.mozilla.org/l10n-central/nl/rev/03b672cc92cb
http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/b6d62c29d99b

    
    

    
  
(In reply to Ton from comment #258)
> (In reply to Tim Maks van den Broek from comment #257)
> > 
> > wil deze patch ook toepassen op central en aurora?
> 
> Yup…
> 
> http://hg.mozilla.org/l10n-central/nl/rev/03b672cc92cb
> http://hg.mozilla.org/releases/l10n/mozilla-aurora/nl/rev/b6d62c29d99b

in central is de entity hernoemd naar calendarproperties.cache2.label

    
    

    
  
We zitten momenteel op versie 1.1 voor thunderbird 9 dus sluit ik deze bug. Als het nodig is kunnen we een bug nieuwe bug openen ( [nl] mozilla-aurora/nl lightning )
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED

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






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: