Endelig har en av utviklerne av glibc lagt inn nb_NO som et ekte locale. Dette gjør at vi kan begynne å flytte oversettelse-filer fra no.po til nb.po. Vi må naturligvis vente til distribusjonene tar dette nye glibc i bruk, men det bør skje i løpet av de neste 2-3 årene.
Desværre så valgte utvikleren å endre navn på no_NO til nb_NO, og endre aliaset nb_NO til no_NO. Konsekvensen er at gettext med den nye glibc ikke vil finne de gamle oversettelsene lengre. Dette vil antagelig føre til at bokmålsoversettelsene vil være fraværende fra linux-distribusjoner i en lengre periode mens overgangen pågår.
Jeg vet ikke helt hva som er den beste måten å fikse dette på. Det kan være at vi bør forsøke å overtale distribusjonene til å beholde no_NO som et ekte locale i noen år, for å unngå dette problemet.
Noen som har synspunkter?
On Tue, Nov 04, 2003 at 10:10:53AM +0100, Petter Reinholdtsen wrote:
Endelig har en av utviklerne av glibc lagt inn nb_NO som et ekte locale. Dette gjør at vi kan begynne å flytte oversettelse-filer fra no.po til nb.po. Vi må naturligvis vente til distribusjonene tar dette nye glibc i bruk, men det bør skje i løpet av de neste 2-3 årene.
Desværre så valgte utvikleren å endre navn på no_NO til nb_NO, og endre aliaset nb_NO til no_NO. Konsekvensen er at gettext med den nye glibc ikke vil finne de gamle oversettelsene lengre. Dette vil antagelig føre til at bokmålsoversettelsene vil være fraværende fra linux-distribusjoner i en lengre periode mens overgangen pågår.
Jeg vet ikke helt hva som er den beste måten å fikse dette på. Det kan være at vi bør forsøke å overtale distribusjonene til å beholde no_NO som et ekte locale i noen år, for å unngå dette problemet.
Noen som har synspunkter?
Kan vi ikke bare kopiere alle no_NO oversettelsene til nb_NO?
hilsen keld
[Keld Jørn Simonsen]
Kan vi ikke bare kopiere alle no_NO oversettelsene til nb_NO?
Jeg ser ikke noe bare i det.
Det er snakk om å oppdatere kildekoden til hundrevis av programvarepakker. Hver gang vi endrer det i kilden, så vil noen som som ennå ikke har localet nb_NO tilgjengelig klage over at oversettelsen ble borte, mens hver gang vi ikke endrer det i kilden, så vil noen som har mistet no_NO klage over at oversettelsen er forsvunnet.
Det vil være mye bråk og mye smerte rundt dette, og jeg regner med at det vil ta 2-3 år før nb_NO er tilgjengelig i de fleste linux-bokser, og minst like lang tid før vi får fikset all kildekoden slik at det blir riktig.
* Petter Reinholdtsen pere@hungry.com [2003-11-04 13:22:00 +0100]:
[Keld Jørn Simonsen]
Kan vi ikke bare kopiere alle no_NO oversettelsene til nb_NO?
Jeg ser ikke noe bare i det.
Det er snakk om å oppdatere kildekoden til hundrevis av programvarepakker. Hver gang vi endrer det i kilden, så vil noen som som ennå ikke har localet nb_NO tilgjengelig klage over at oversettelsen ble borte, mens hver gang vi ikke endrer det i kilden, så vil noen som har mistet no_NO klage over at oversettelsen er forsvunnet.
Hvilke kildekode-endringer snakker du om her? Det er da vel ingen kildekode- endringer som er nødvendig for å støtte nye locales? Utfordringen ligger vel bare på filsystem-nivå (og Makefile)? Alle pakker må få et dobbelt sett med oversettelser for norsk støtte, og alle oversettere må passe på at de tar utgangspunkt ifra (og endrer) riktig fil.
For oversettelser underlagt Translation Project kan mye håndteres via TP-roboten, så der ser jeg ikke noen store hindre. Hvordan det er i Gnome-verdenen og KDE-verdenen vet jeg ikke like mye om.
Eivind
[Eivind Tagseth]
Hvilke kildekode-endringer snakker du om her?
Stort sett 'mv no.po nb.po; sed s/no/nb/ Makefile'. :)
Det er da vel ingen kildekode- endringer som er nødvendig for å støtte nye locales? Utfordringen ligger vel bare på filsystem-nivå (og Makefile)?
Jeg ser på hele kildekodepakken som kildekode. Det inkluderer Makefile og navn på filene.
Alle pakker må få et dobbelt sett med oversettelser for norsk støtte, og alle oversettere må passe på at de tar utgangspunkt ifra (og endrer) riktig fil.
Synkroniserte doble oversettelser (nb.po og no.po) kan være en mulighet, men jeg er ikke sikker på om det vil gå bra. Jeg er litt usikker på om byggesystemet for oversettelser vil håndtere det ut av boksen.
For oversettelser underlagt Translation Project kan mye håndteres via TP-roboten, så der ser jeg ikke noen store hindre.
Hvilke små hindre ser du da? Jeg forstår ikke hvorfor flere bare ser bagateller og små hindre der jeg ser mye arbeid og innkonsistens som vil vare i flere år.
Hvordan det er i Gnome-verdenen og KDE-verdenen vet jeg ikke like mye om.
KDE bruker allerede nb som språkkode for bokmål. Gnome bruker glibc-localer og gettext, og må fikses slik som alle de andre pakkene som bruker dette.
* Petter Reinholdtsen pere@hungry.com [2003-11-04 15:19:02 +0100]:
Hvilke kildekode-endringer snakker du om her?
Stort sett 'mv no.po nb.po; sed s/no/nb/ Makefile'. :)
Ok, da er jeg med.
For oversettelser underlagt Translation Project kan mye håndteres via TP-roboten, så der ser jeg ikke noen store hindre.
Hvilke små hindre ser du da? Jeg forstår ikke hvorfor flere bare ser bagateller og små hindre der jeg ser mye arbeid og innkonsistens som vil vare i flere år.
Vel, for TP er det ganske enkelt. Så lenge robot-vedlikeholderene er villige til å gjøre de endringene som må til for at en oversettelse som gjelder nb automatisk blir kopiert til no vil vedlikeholderene av programpakker automatisk motta 2 po-filer hver gang noen sender inn en ny/oppdatert norsk oversettelse til roboten.
Nå måtte jeg ned i epost-arkivene her, for her var det noe som ikke stemte.
I august 2001(!) ble det gjort en endring i TP-prosjektet der alle no-oversettelser ble kopiert inn i nb. no-området ble liggende som det var, men read-only. Følgelig burde alle oversettelser gjort siden blitt til nb_NO-oversettelser. Også i denne diskusjonen ble det forøvrig hevdet av Kjetil Torgrim Homme at det burde være et alias fra no_NO til nb_NO. Er det virkelig ikke mulig å få endret dette?
I min /usr/share/local/nb/LC_MESSAGES finner jeg coreutils, nano og textutils. Det er imidlertid kjedelig lite aktivitet på oversettelsene under TP-prosjektet, så koordinatoren burde vel hatt et spark bak.
Situasjonen for oversettelser under TP-prosjektet er altså i dag at nye oversettelser/oppdateringer blir nb-oversettelser, mens no- oversettelsene ikke blir vedlikeholdt. Det er kanskje like greit, så har oversetterne ekstra motivasjon for å oppdatere oversettelsene?
For prosjekter som ikke hører hjemme under TP-prosjektet ser jeg følgende hindre:
o Oversetterene må slutte å sende no-filer, og kun sende nb (evt begge) o Programansvarlig må kunne motta en nb-fil. Men dette er vel ikke vanskeligere enn å motta en zu-fil.
Det største problemet er vel at det eneste fornuftige valget for et alias er et alias fra no_NO til nb_NO, og så lenge dette aliaset ikke er på plass vil skiftet mellom no_NO til nb_NO være et problem for _brukerne_.
Har du en URL til en bug-rapport eller liknende som omhandler dette og som den aktuelle libc-utvikleren har oppdatert?
Eivind (norsk TP-koordinator)
[Eivind Tagseth]
Vel, for TP er det ganske enkelt. Så lenge robot-vedlikeholderene er villige til å gjøre de endringene som må til for at en oversettelse som gjelder nb automatisk blir kopiert til no vil vedlikeholderene av programpakker automatisk motta 2 po-filer hver gang noen sender inn en ny/oppdatert norsk oversettelse til roboten.
De problemene jeg ser er derimot i hele prosessen fra nb.po ankommer utvikleren av pakke X, til den er installert og i bruk hos alle brukerne av pakke X. Det vil ta lang tid før oversettelsene har gått igjennom hele den prosessen.
Også i denne diskusjonen ble det forøvrig hevdet av Kjetil Torgrim Homme at det burde være et alias fra no_NO til nb_NO.
Hvis du med et alias mener en no_NO-oppføring i /usr/share/locale/locale.alias, så er det med i det nye oppsettet. Det er bare det at gettext ikke bruker disse aliasene, og det har dermed ikke den ønskede effekt.
Er det virkelig ikke mulig å få endret dette?
Det vil tiden vise. nb_NO gikk inn i glibc CVS i dag.
Situasjonen for oversettelser under TP-prosjektet er altså i dag at nye oversettelser/oppdateringer blir nb-oversettelser, mens no- oversettelsene ikke blir vedlikeholdt. Det er kanskje like greit, så har oversetterne ekstra motivasjon for å oppdatere oversettelsene?
Jeg ser ikke noe stort problem på TP-siden av oversetterprosessen. Jeg ser derimot et større problem i at alle oversettelsene i /usr/share/locale/no/LC_MESSAGES/ ignoreres så snart nb_NO blir det "ekte" localet, og no_NO blir et alias til nb_NO. Det vil skape bråk og smerte.
Det største problemet er vel at det eneste fornuftige valget for et alias er et alias fra no_NO til nb_NO, og så lenge dette aliaset ikke er på plass vil skiftet mellom no_NO til nb_NO være et problem for _brukerne_.
Hva slags alias tenker du på her? Så vidt jeg vet er det ikke mulig å bruke et alias for å jobbe seg rundt dette.
Har du en URL til en bug-rapport eller liknende som omhandler dette og som den aktuelle libc-utvikleren har oppdatert?
GNU GNATS er desverre nede, og det var der glibc hadde feilrapportene sine. Det eneste som finnes er mailinglista libc-alpha, og føljetingen som har gått der de siste månedene.
Min siste patch er tilgjengelig fra URL:http://sources.redhat.com/ml/libc-alpha/2003-06/msg00133.html. Svaret kom i dag, URL:http://sources.redhat.com/ml/libc-alpha/2003-11/msg00031.html.
Hvis du eller noen andre er interessert i å diskutere glibc-localer, så se også min mail URL:http://sources.redhat.com/ml/libc-alpha/2003-10/msg00149.html, og meld deres interesse.
* Petter Reinholdtsen pere@hungry.com [2003-11-04 17:19:24 +0100]:
De problemene jeg ser er derimot i hele prosessen fra nb.po ankommer utvikleren av pakke X, til den er installert og i bruk hos alle brukerne av pakke X. Det vil ta lang tid før oversettelsene har gått igjennom hele den prosessen.
Ja, jeg begynner å skjønne bekymringene dine nå. For oversetterne er alt greit, for utviklerne er også alt greit. Men for brukerne som skal bruke alle disse pakkene på en maskin vil det fort bli kaos, har jeg forstått deg riktig da?
Hvis du med et alias mener en no_NO-oppføring i /usr/share/locale/locale.alias, så er det med i det nye oppsettet. Det er bare det at gettext ikke bruker disse aliasene, og det har dermed ikke den ønskede effekt.
Da misforsto jeg deg. Hvorfor har ikke alias-filen effekt for gettext? alias-filen fungerer helt fint hos meg...
Men den hjelper jo ikke for vårt problem, da måtte vi hatt en måte å si at man skulle lete i no kun dersom filen ikke ble funnet i nb...
Jeg ser ikke noe stort problem på TP-siden av oversetterprosessen. Jeg ser derimot et større problem i at alle oversettelsene i /usr/share/locale/no/LC_MESSAGES/ ignoreres så snart nb_NO blir det "ekte" localet, og no_NO blir et alias til nb_NO. Det vil skape bråk og smerte.
Distribusjonene kan selvsagt løse dette enkelt ved å lage et shell-script som kopierer inn no-oversettelsene der nb-oversettelsene mangler. Men det spørs vel om de er villige til å gjøre en sånn spesialtilpasning for norsk språk?
Eivind
Distribusjonene kan selvsagt løse dette enkelt ved å lage et shell-script som kopierer inn no-oversettelsene der nb-oversettelsene mangler. Men det spørs vel om de er villige til å gjøre en sånn spesialtilpasning for norsk språk?
Vil det ikkje vera enklast at omsetjarane sender inn identiske no.po- og nb.po-filer i nokre år? Det er jo alt ein del pakkar i TP som har både nb- og no-filer.
[Eivind Tagseth]
Ja, jeg begynner å skjønne bekymringene dine nå. For oversetterne er alt greit, for utviklerne er også alt greit. Men for brukerne som skal bruke alle disse pakkene på en maskin vil det fort bli kaos, har jeg forstått deg riktig da?
Ja. Og når brukerne klager, så vil distribusjonene motta dem, og utviklerne måtte forholde seg til dem, og utviklerne vil skylde på oversetterne som endrer språkkode uten en særlig god grund.
Da misforsto jeg deg. Hvorfor har ikke alias-filen effekt for gettext? alias-filen fungerer helt fint hos meg...
Vet ikke hvorfor gettext fungerer som den gjør.
Distribusjonene kan selvsagt løse dette enkelt ved å lage et shell-script som kopierer inn no-oversettelsene der nb-oversettelsene mangler. Men det spørs vel om de er villige til å gjøre en sånn spesialtilpasning for norsk språk?
Eller de kan la no_NO eksistere som locale i overgangsperioden.
* Petter Reinholdtsen pere@hungry.com [2003-11-05 10:05:40 +0100]:
Ja. Og når brukerne klager, så vil distribusjonene motta dem, og utviklerne måtte forholde seg til dem, og utviklerne vil skylde på oversetterne som endrer språkkode uten en særlig god grund.
Og så kan vi skylde på ISO? ;)
Distribusjonene kan selvsagt løse dette enkelt ved å lage et shell-script som kopierer inn no-oversettelsene der nb-oversettelsene mangler. Men det spørs vel om de er villige til å gjøre en sånn spesialtilpasning for norsk språk?
Eller de kan la no_NO eksistere som locale i overgangsperioden.
Ja, og dette er en 1 til 2-linjers patch mot /use/share/locale/locale.alias, ikke sant? Som hver enkelt distribusjon må legge til for libc i de neste X utgivelsene sine.
Men for at folk skal få de mest oppdaterte oversettelsene samtidig som de ikke går glipp av gamle oversettelser må distroene også sette LANGUAGE="nb_NO:no_NO".
Det ser ut som om de ikke slipper unna spesialhåndtering for norsk uansett.
Eivind
[Eivind Tagseth]
Eller de kan la no_NO eksistere som locale i overgangsperioden.
Ja, og dette er en 1 til 2-linjers patch mot /use/share/locale/locale.alias, ikke sant?
Nei, det holder som sagt ikke at no_NO er et alias. Det må være et ekte locale for at gettext skal finne oversettelsen som bruker den språkkoden.
Som hver enkelt distribusjon må legge til for libc i de neste X utgivelsene sine.
De må legge ved /usr/share/i18n/locales/no_NO, og fjerne aliaset no_NO fra /use/share/locale/locale.alias for at det skal være mulig å bruke LANGUAGES=nb_NO:nb:no_NO:no
Det ser ut som om de ikke slipper unna spesialhåndtering for norsk uansett.
Det er riktig, men den ene spesialhåndteringen (LANGUAGES=...) kan brukeren gjøre selv, den andre kan brukeren ikke gjøre (legge ved no_NO).