ArcaOS 5.0.6 released
-
- Beiträge: 190
- Registriert: Fr 3. Jan 2014, 09:42
ArcaOS 5.0.6 released
Hallo,
habe gerade eine Email mit der Ankündigung für AOS 5.0.6 erhalten. Leider sagen weder Readme noch Changelog auf der Webseite genauer was sich geändert hat. Habe gerade das ISO angefordert - vielleicht verrät das mehr.
Die Readme im ISO hat die Infos:
Summary of changes 5.0.6
- Updated JFS to 1.9.8.
- Updated brlaser CUPS print driver.
- Updated NetDrive Samba plugin to 3.7.1.
- Updated VirtualBox Additions to 6.1.12; improved packaging.
- Updated FAT32 to 5.0.3.
- Updated ACPI to 3.23.14.
- Updated eCo Runtime Base & Win to 20200525.
- Updated NAPS help (minor).
- Updated Panorama to 1.16.
- Updated TestLog to 3.32.
- Updated PRINTMAN to 0.8.6 (proper filtering of non-current-codepage PPD strings).
- Updated CUPSWIZ to 1.20 (proper filtering of non-current-codepage PPD strings).
- Fixed repeating "EPSON" string in generated printer driver list.
- (Installer) Various minor layout fixes.
- (Installer) Moved Media Folder creation to phase 2 to avoid potential hang in phase 3.
habe gerade eine Email mit der Ankündigung für AOS 5.0.6 erhalten. Leider sagen weder Readme noch Changelog auf der Webseite genauer was sich geändert hat. Habe gerade das ISO angefordert - vielleicht verrät das mehr.
Die Readme im ISO hat die Infos:
Summary of changes 5.0.6
- Updated JFS to 1.9.8.
- Updated brlaser CUPS print driver.
- Updated NetDrive Samba plugin to 3.7.1.
- Updated VirtualBox Additions to 6.1.12; improved packaging.
- Updated FAT32 to 5.0.3.
- Updated ACPI to 3.23.14.
- Updated eCo Runtime Base & Win to 20200525.
- Updated NAPS help (minor).
- Updated Panorama to 1.16.
- Updated TestLog to 3.32.
- Updated PRINTMAN to 0.8.6 (proper filtering of non-current-codepage PPD strings).
- Updated CUPSWIZ to 1.20 (proper filtering of non-current-codepage PPD strings).
- Fixed repeating "EPSON" string in generated printer driver list.
- (Installer) Various minor layout fixes.
- (Installer) Moved Media Folder creation to phase 2 to avoid potential hang in phase 3.
Zuletzt geändert von morcvomorc am Di 1. Sep 2020, 00:04, insgesamt 1-mal geändert.
Uups, sowas gab es ja noch nie im Forum.....neue Version ArcaOS und keine Diskussionsbeiträge. Seid ihr alle noch da?
Thomas
Thomas
Hi Thomas,
ja ich bin noch da. Download habe ich auch schon gezogen, aber weiter bin ich noch nicht.
ja ich bin noch da. Download habe ich auch schon gezogen, aber weiter bin ich noch nicht.
Hallo Thomas,
das ISO-File ist runter geladen, der USB-Stick erstellt, bis in den Wartungsbildschirm gestartet. Soweit okay. Da die Änderungen zur 5.0.5 im wesentlichen nur Treiber betreffen, die bei der Subscription ebenfalls zum Download stehen, habe ich meine 5.0.5 nur mit den Treibern aus der Subscription modernisiert.
Hintergrund ist, dass ich die 5.0.5 als Arbeitssystem weitestgehend "eingedeutscht" habe. Alles was sich umbenennen lies ist umbenannt. Einen guten Anteil an der deutschen Oberfläche hat XWP
![Überglücklich :D](./images/smilies/icon_e_biggrin.gif)
Mit der 5.0.5 bis ich sehr zufrieden, habe lediglich für mein X250 wieder auf Lars USB-Treiber zurück gegriffen, da die AN Treiber meine externe Tastatur an der Dockingstation nicht zuverlässig finden.
Grüße aus Potsdam,
Mike
Ich bin endlich mal wieder dazu gekommen, das Booten vom USB-Stick auszuprobieren. Das klappt auch (Update oder Neuinstallation) zunächst, bricht dann aber zu Beginn der Phase 2 mit der Meldung ab, das AiR-BOOT nicht mehr richtig installiert ist, vgl. OS2world.com.
Weiter bin ich noch nicht gekommen. Wenn ich das reproduziert kriege und ein paralleles System von DVD installiert drauf hab, werd ich bei Arca Noae einen Fehler melden.
Ergänzung: Ich musste tatsächlich AiR-BOOT neu installieren. Der wurde mit 5.0.2 auf Version 1.1.4 aktualisiert. Das ging mit der Maintenance Console über
System Management -> Disk -> Manage volumes (graphical) und dann
minilvm.exe (Installation Volume Manager) -> System -> Boot menu -> Install/update.
Danach hat alles geklappt.
Eine Andeutung dazu findet man auch im AN-Wiki:
Code: Alles auswählen
AiR-BOOT: !ATTENTION!
- The code of AiR-BOOT is not intact anymore.
Please boot via AIR-BOOT disc to restore AiR-BOOT.
System halted. Please press RESET.
Ergänzung: Ich musste tatsächlich AiR-BOOT neu installieren. Der wurde mit 5.0.2 auf Version 1.1.4 aktualisiert. Das ging mit der Maintenance Console über
System Management -> Disk -> Manage volumes (graphical) und dann
minilvm.exe (Installation Volume Manager) -> System -> Boot menu -> Install/update.
Danach hat alles geklappt.
Eine Andeutung dazu findet man auch im AN-Wiki:
AiR-BOOT can be installed using the Installation Volume Manager (the Manage Volumes button) in the installer.
Zuletzt geändert von aschn am Mi 21. Okt 2020, 12:02, insgesamt 2-mal geändert.
Andreas Schnellbacher
die Installation von AN 5.06 stockte bei mir mit einer Meldung, dass Zeile 149 der ConfigSys nicht
abgearbeitet werden konnte. Es handelt sich um VMOUSE.SYS.
Ein Weiter mit "Enter" fuktionierte leider nicht (obwohl mein Ticket zum gleichen Problem bei AN 5.05
als behoben galt). Es folgte ein ärgerliches chkdsk.
Die Datei VMOUSE.sys befand sich tatsächlich nicht im Ordner OS2/MDOS.
Ich habe sie von einer Parallelinstallation in dieses Verzeichnis kopiert, bekam aber beim Reboot
die gleiche Meldung.
Habe dann die Datei wieder gelöscht und Zeile 149 mit einem REM versehen.
Die weitere Installation lief anstandslos.
Allerdings findet sich VMOUSE.SYS nicht im Ordner OS2/MDOS.
abgearbeitet werden konnte. Es handelt sich um VMOUSE.SYS.
Ein Weiter mit "Enter" fuktionierte leider nicht (obwohl mein Ticket zum gleichen Problem bei AN 5.05
als behoben galt). Es folgte ein ärgerliches chkdsk.
Die Datei VMOUSE.sys befand sich tatsächlich nicht im Ordner OS2/MDOS.
Ich habe sie von einer Parallelinstallation in dieses Verzeichnis kopiert, bekam aber beim Reboot
die gleiche Meldung.
Habe dann die Datei wieder gelöscht und Zeile 149 mit einem REM versehen.
Die weitere Installation lief anstandslos.
Allerdings findet sich VMOUSE.SYS nicht im Ordner OS2/MDOS.
Zuletzt geändert von andreas am Mi 9. Sep 2020, 16:57, insgesamt 2-mal geändert.
Hallo OS2-ler,
habe jetzt auf verschiedenen HP-Rechnern auch neuere Generationen ohne Probleme ca. 10 Installationen ArcaOS 5.0.6 durchgeführt. (Boot von USB-Stick und CD-ROM). Darunter auch reine USB3.x Rechner. Mache aus Prinzip immer Neuinstallationen.
Ach, ja und auch unter VirtualBox 6.12.
Nutzungsumfang des ArcaOS ist bei mir übersichtlich.
Keine Probleme.
Schönes Wochenende aus dem sonnigen OWL
Dirk
PS. RFID Reader & BArcode Scanner als HID funktionieren auch tadellos.
habe jetzt auf verschiedenen HP-Rechnern auch neuere Generationen ohne Probleme ca. 10 Installationen ArcaOS 5.0.6 durchgeführt. (Boot von USB-Stick und CD-ROM). Darunter auch reine USB3.x Rechner. Mache aus Prinzip immer Neuinstallationen.
Ach, ja und auch unter VirtualBox 6.12.
Nutzungsumfang des ArcaOS ist bei mir übersichtlich.
Keine Probleme.
Schönes Wochenende aus dem sonnigen OWL
Dirk
PS. RFID Reader & BArcode Scanner als HID funktionieren auch tadellos.
Zuletzt geändert von Dirk am Fr 11. Sep 2020, 12:39, insgesamt 5-mal geändert.
Hehe und ich dachte schon keine Diskussionsbeiträge nach einem neuen Release bedeutet schlicht, daß alles funktioniert. - a la linux: Keine Meldung, gute Meldung. : ]
Aber die Arbeiten am DE-Release machen Fortschritte. Als Mitwirkender sehe und arbeite ich aktiv am Fortschritt. Das Rollout auf Version 5.1 zu verlegen, war eine gute Idee, da es hier und da noch englische Bereiche gibt.
Auch verzögert sich das DE-Release stellenweise dadurch, daß der technische Fortschritt (z.B. UEFI-Support) bereits überetzte Dinge erneut auf den Schirm bringt. Neue und geänderte Textbereiche müssen somit erneut übersetzt werden, damit die Übersetzung mit dem Fortschritt mithält. Dies in Bezug auf OS/2 zu schreiben, ist schon was Besonderes, meint ihr nicht auch? : )
Manchmal verzögert sich eine DE-Beta auch nur, weil wichtige Bereiche keine (neuen) Übersetzungen haben! Und dann ist natürlich die Frage... sollte die Priorität auf Sprachen liegen, oder auf Funktionalität? Sollte die Internationalität des Produkts Vorrang vor z.B. Neuerungen bei UEFI haben?
Oder anders gefragt, stellt euch vor, USB3 und UEFI wäre FERTIG, und in Deutsch aber gibt es noch bislang nur alte DE-Ressourcen, die nicht auf die neuen EN-Texte passen, die aber die Sofware voraussetzt. Sollen alle fertigen ArcaOS-Sprachen jetzt darauf warten, daß jede andere Sprache den gleichen Übersetzungsstand erreicht?
DAS ist der Grund, warum es ArcaOS bis jetzt nur auf Englisch gibt. Das ist die Sprache, in der das Produkt entwickelt wird.
Features haben Priorität vor Internationalität, und da es zuwenige Übersetzer gibt, ist die Last auf nur wenigen Schultern verteilt.
Weitere DE-Übersetzer könnten den Fortschritt beschleunigen, bedingen aber Maßnahmen zur Koordinierung.. damit nicht mehrere Übersetzer wortlios das gleiche Ticket übersetzen. (Ressourcenverschwendung)
Falls also jemand mitwirken mag, sollte sich echt bei Lewis melden. - Gab ja mal die Umfrage, ob weitere DE-Übersetzer gut wären, und ich habe für ein DEUTLICHES JA gestimmt.
Dann gehts flotter. : )
Aber die Arbeiten am DE-Release machen Fortschritte. Als Mitwirkender sehe und arbeite ich aktiv am Fortschritt. Das Rollout auf Version 5.1 zu verlegen, war eine gute Idee, da es hier und da noch englische Bereiche gibt.
Auch verzögert sich das DE-Release stellenweise dadurch, daß der technische Fortschritt (z.B. UEFI-Support) bereits überetzte Dinge erneut auf den Schirm bringt. Neue und geänderte Textbereiche müssen somit erneut übersetzt werden, damit die Übersetzung mit dem Fortschritt mithält. Dies in Bezug auf OS/2 zu schreiben, ist schon was Besonderes, meint ihr nicht auch? : )
Manchmal verzögert sich eine DE-Beta auch nur, weil wichtige Bereiche keine (neuen) Übersetzungen haben! Und dann ist natürlich die Frage... sollte die Priorität auf Sprachen liegen, oder auf Funktionalität? Sollte die Internationalität des Produkts Vorrang vor z.B. Neuerungen bei UEFI haben?
Oder anders gefragt, stellt euch vor, USB3 und UEFI wäre FERTIG, und in Deutsch aber gibt es noch bislang nur alte DE-Ressourcen, die nicht auf die neuen EN-Texte passen, die aber die Sofware voraussetzt. Sollen alle fertigen ArcaOS-Sprachen jetzt darauf warten, daß jede andere Sprache den gleichen Übersetzungsstand erreicht?
DAS ist der Grund, warum es ArcaOS bis jetzt nur auf Englisch gibt. Das ist die Sprache, in der das Produkt entwickelt wird.
Features haben Priorität vor Internationalität, und da es zuwenige Übersetzer gibt, ist die Last auf nur wenigen Schultern verteilt.
Weitere DE-Übersetzer könnten den Fortschritt beschleunigen, bedingen aber Maßnahmen zur Koordinierung.. damit nicht mehrere Übersetzer wortlios das gleiche Ticket übersetzen. (Ressourcenverschwendung)
Falls also jemand mitwirken mag, sollte sich echt bei Lewis melden. - Gab ja mal die Umfrage, ob weitere DE-Übersetzer gut wären, und ich habe für ein DEUTLICHES JA gestimmt.
Dann gehts flotter. : )
Mathias, ich möchte Deinen Aufruf nicht zerreden. Ich will aber eine Sache verdeutlichen, die Anderen nicht so klar ist:
Bei den übersetzten Versionen geht es nicht nur um übersetzte Texte. (Wär schön, wenn das so wäre.) In dem Moment, wo z.B. irgendeine Komponente verändert wird, muss sie auch auf alle nichtenglischsprachigen Versionen verteilt werden und dort auch funktionieren. Das testet natürlich so gut wie Keiner, außer "so ein paar Übersetzern".
Bei Mensys war das schon ein Riesenproblem, dass sie die anderssprachigen Versionen nicht nur nicht synchron gehalten hatten, sondern auf offensichtliche Fehler, wie Installation funktioniert nicht, aber mit der englischsprachen geht es, kaum reagiert hatten. Ich kann mich da an zwei Ereignisse erinnern. Das erste war überhebliches (?) Ignorieren meiner Fehlermeldung seitens des Kernel-Entwicklers, das zweite war wohl zeitliche Überforderung (?), dass SMouse lange nicht mehr funktioniert hatte.
Mit Lewis ist das alles etwas anders. Aber dass die anderssprachigen Versionen so gut wie nicht getestet, sondern nur gebaut werden, ist bestehen geblieben. Immerhin ist die Reaktionszeit auf offensichtlich Fehler richtig gut.
Das Hauptproblem ist aber nach wie vor dasselbe: Eine anderssprachige Version ist immer eine andere Version. Es sind nicht nur die Texte ausgetauscht - leider. Um dass zu erreichen, müsste man die gesamte Installation ändern. Einzelne Komponenten machen das vor, dass nur Textdateien oder kompilierte Textdateien ausgetauscht werden, die Funktionalität aber die gleiche bleibt. Das ist nicht gewollt, sondern alles beruht noch auf dem IBM-Installationsprogramm (CID mit neuer GUI). Das zu umgehen wäre schon ein Riesenschritt, aber einer, der vielleicht in kleinen Abschnitten umzusetzen wäre.
Zusätzlich sollte die Verwendung von Texten so geändert werden (jedenfalls von Komponenten, die noch weiter entwickelt werden), dass, falls ein anderssprachiger Text nicht vorhanden ist, der englichsprachige genommen wird. Man müsste dafür die Quelldateien ändern. (Bei IBM-Komponenten fällt das natürlich flach, aber die ändern sich ja auch nicht mehr.) Auch das wäre eine größere Veränderung, aber eine, die sich lohnen würde. Alex hat mit seinen VX-REXX-Programmen einen anderen Weg gewählt: Es hat alle Text in der GUI mit einer Textkurzfassung belegt, die in eckigen Klammern steht. Falls z.B: in der de_DE-Version ein Text fehlt, fällt der dadurch auf, dass er in eckigen Klammern steht. Das Programm bleibt dann aber trotzdem benutzbar. Statt dessen sind natürlich noch andere Möglichkeiten denkbar, die tatsächlich in so einem Ernstfall auf die (dann auch vorhandene) englischsprachige Textdatei zurückgreifen.
Bei den übersetzten Versionen geht es nicht nur um übersetzte Texte. (Wär schön, wenn das so wäre.) In dem Moment, wo z.B. irgendeine Komponente verändert wird, muss sie auch auf alle nichtenglischsprachigen Versionen verteilt werden und dort auch funktionieren. Das testet natürlich so gut wie Keiner, außer "so ein paar Übersetzern".
Bei Mensys war das schon ein Riesenproblem, dass sie die anderssprachigen Versionen nicht nur nicht synchron gehalten hatten, sondern auf offensichtliche Fehler, wie Installation funktioniert nicht, aber mit der englischsprachen geht es, kaum reagiert hatten. Ich kann mich da an zwei Ereignisse erinnern. Das erste war überhebliches (?) Ignorieren meiner Fehlermeldung seitens des Kernel-Entwicklers, das zweite war wohl zeitliche Überforderung (?), dass SMouse lange nicht mehr funktioniert hatte.
Mit Lewis ist das alles etwas anders. Aber dass die anderssprachigen Versionen so gut wie nicht getestet, sondern nur gebaut werden, ist bestehen geblieben. Immerhin ist die Reaktionszeit auf offensichtlich Fehler richtig gut.
Das Hauptproblem ist aber nach wie vor dasselbe: Eine anderssprachige Version ist immer eine andere Version. Es sind nicht nur die Texte ausgetauscht - leider. Um dass zu erreichen, müsste man die gesamte Installation ändern. Einzelne Komponenten machen das vor, dass nur Textdateien oder kompilierte Textdateien ausgetauscht werden, die Funktionalität aber die gleiche bleibt. Das ist nicht gewollt, sondern alles beruht noch auf dem IBM-Installationsprogramm (CID mit neuer GUI). Das zu umgehen wäre schon ein Riesenschritt, aber einer, der vielleicht in kleinen Abschnitten umzusetzen wäre.
Zusätzlich sollte die Verwendung von Texten so geändert werden (jedenfalls von Komponenten, die noch weiter entwickelt werden), dass, falls ein anderssprachiger Text nicht vorhanden ist, der englichsprachige genommen wird. Man müsste dafür die Quelldateien ändern. (Bei IBM-Komponenten fällt das natürlich flach, aber die ändern sich ja auch nicht mehr.) Auch das wäre eine größere Veränderung, aber eine, die sich lohnen würde. Alex hat mit seinen VX-REXX-Programmen einen anderen Weg gewählt: Es hat alle Text in der GUI mit einer Textkurzfassung belegt, die in eckigen Klammern steht. Falls z.B: in der de_DE-Version ein Text fehlt, fällt der dadurch auf, dass er in eckigen Klammern steht. Das Programm bleibt dann aber trotzdem benutzbar. Statt dessen sind natürlich noch andere Möglichkeiten denkbar, die tatsächlich in so einem Ernstfall auf die (dann auch vorhandene) englischsprachige Textdatei zurückgreifen.
Andreas Schnellbacher
Naja, die nicht-englisch-sprachigen Versionen sollen durch die Übersetzer selbst und auch durch die Tester-Gruppe getestet werden.
In meinen (meist) ellenlangen Mails werden alle Fundstellen aufgeführt, wo ich noch Bugs oder Englisch gefunden habe.
Auch Sandra hatte letztens recht umfangreich getestet, resultierend in einem längeren Mailbericht an die Gruppe.
Ein Beispiel, daß reines Übersetzen nicht ausreicht, ist etwa das Verhalten (damals) der FORMAT.COM: Hier reichte es nicht aus, die Texte zu übersetzen, sondern die Entwickler mußten auch bestimmte Eingaben, die der Nutzer macht, auf Tauglichkeit neu bewerten. Z.B. die Frage.. "Formatieren? (J/N)".
Wenn der Anwender "j" drückt, passierte einfach nichts. Warum? Die Anwendung erwartet "y". Alle anderen Eingaben führten zu "NEIN". (mittlerweise behoben)
Solche Nicklichkeiten fallen natürlich beim regulären Testen nicht auf, bzw. stehen nicht auf dem Testplan. Weil, wer formatiert schon dauernd, bzw. rechnet mit solchen Problemen im Detail..
Klar, theoretisch müßte ein Tester jede nur erdenkliche Kleinigkeit ausprobieren, alles was das Betriebssystem und seine mitgelieferten Anwendungen so mitbringt.
Die E-Mails "things to test" sind eine Art Laufzettel, umfassen aber meist neue Features, und keine grundlegenden, längst als "im Sack" geglaubten Anwendungen, wie FORMAT.COM und co.
Jedoch werden solche Probleme meist SEHR flott behoben. Da kann man echt nicht meckern.
Z.B. in WINOS2 fiel mir beim Testen einer DE-Beta im Dialog zum Desktop-Hintergrund auf, daß wenn man ihn betritt, und ohne eine Änderung durchzuführen gleich wieder OK drückt, kommt eine Fehlermeldung, die besagt, daß "(none)" keine gültige Angabe ist. (Der Dialog erwartet in der DE-Version "(kein)" für kein Hintergrundbild.)
--> Ticket angelegt, Lewis hat sich am selben Tag noch damit befaßt (schläft der eigentlich jemals?? xD). Ein paar Tage danach war das Problem diagnostiziert und behoben: Der IBM-Installer hat einfach englische Strings in die ... war es die WIN.INI... eingetragen, und somit wurde jedes Mal beim Öffnen des Dialoges (wenn kein Hintergrundbild ausgewählt war) "(none)" eingetragen. - Sehr nervig.
Die Behebung des Problems war möglich .. und wupp wars in der nächsten Beta gefixt.
Gleiches gilt für das "0 Byte frei"-Problem im WINOS2-Dateimanager. - Gemeldet, gefixt, geht nun. : )
Man muß nur ausgiebigst jedes Detail testen und wirklich überall alles auseinandernehmen. Dann findet man schon hier und da was.
Ding ist nur, man hat meist nicht soviel Zeit. Daher kann man nur bestimmte Sachen ausgiebig testen, und andere Probleme fallen eher zufällig auf, oder auch nicht.
Lösung wären Testpläne verteilt auf verschiedene Tester der DE-Version. Aber selbst dann testet man mehrere Bereiche, in denen man ggf. gar keine Fehler findet, andere hingegen, in denen man keine Probleme erwartet, werden nicht getestet und weisen dennoch Probleme auf, die dann erst der Nutzer findet.
Das alte Problem.. man kann nicht 100% alles perfekt testen. Zeit und Ressourcen sind einfach nicht da.
In meinen (meist) ellenlangen Mails werden alle Fundstellen aufgeführt, wo ich noch Bugs oder Englisch gefunden habe.
Auch Sandra hatte letztens recht umfangreich getestet, resultierend in einem längeren Mailbericht an die Gruppe.
Ein Beispiel, daß reines Übersetzen nicht ausreicht, ist etwa das Verhalten (damals) der FORMAT.COM: Hier reichte es nicht aus, die Texte zu übersetzen, sondern die Entwickler mußten auch bestimmte Eingaben, die der Nutzer macht, auf Tauglichkeit neu bewerten. Z.B. die Frage.. "Formatieren? (J/N)".
Wenn der Anwender "j" drückt, passierte einfach nichts. Warum? Die Anwendung erwartet "y". Alle anderen Eingaben führten zu "NEIN". (mittlerweise behoben)
Solche Nicklichkeiten fallen natürlich beim regulären Testen nicht auf, bzw. stehen nicht auf dem Testplan. Weil, wer formatiert schon dauernd, bzw. rechnet mit solchen Problemen im Detail..
Klar, theoretisch müßte ein Tester jede nur erdenkliche Kleinigkeit ausprobieren, alles was das Betriebssystem und seine mitgelieferten Anwendungen so mitbringt.
Die E-Mails "things to test" sind eine Art Laufzettel, umfassen aber meist neue Features, und keine grundlegenden, längst als "im Sack" geglaubten Anwendungen, wie FORMAT.COM und co.
Jedoch werden solche Probleme meist SEHR flott behoben. Da kann man echt nicht meckern.
Z.B. in WINOS2 fiel mir beim Testen einer DE-Beta im Dialog zum Desktop-Hintergrund auf, daß wenn man ihn betritt, und ohne eine Änderung durchzuführen gleich wieder OK drückt, kommt eine Fehlermeldung, die besagt, daß "(none)" keine gültige Angabe ist. (Der Dialog erwartet in der DE-Version "(kein)" für kein Hintergrundbild.)
--> Ticket angelegt, Lewis hat sich am selben Tag noch damit befaßt (schläft der eigentlich jemals?? xD). Ein paar Tage danach war das Problem diagnostiziert und behoben: Der IBM-Installer hat einfach englische Strings in die ... war es die WIN.INI... eingetragen, und somit wurde jedes Mal beim Öffnen des Dialoges (wenn kein Hintergrundbild ausgewählt war) "(none)" eingetragen. - Sehr nervig.
Die Behebung des Problems war möglich .. und wupp wars in der nächsten Beta gefixt.
Gleiches gilt für das "0 Byte frei"-Problem im WINOS2-Dateimanager. - Gemeldet, gefixt, geht nun. : )
Man muß nur ausgiebigst jedes Detail testen und wirklich überall alles auseinandernehmen. Dann findet man schon hier und da was.
Ding ist nur, man hat meist nicht soviel Zeit. Daher kann man nur bestimmte Sachen ausgiebig testen, und andere Probleme fallen eher zufällig auf, oder auch nicht.
Lösung wären Testpläne verteilt auf verschiedene Tester der DE-Version. Aber selbst dann testet man mehrere Bereiche, in denen man ggf. gar keine Fehler findet, andere hingegen, in denen man keine Probleme erwartet, werden nicht getestet und weisen dennoch Probleme auf, die dann erst der Nutzer findet.
Das alte Problem.. man kann nicht 100% alles perfekt testen. Zeit und Ressourcen sind einfach nicht da.
Scanner:
- Honeywell 1400g
- CipherLab 1560P (cordless)
RFID (13 MHz):
- Elatec TWN3 (Reader / Writer) --> werde bald den neuen TWN4 MultiTec testen können (alle Frequenzbereiche)
- NoName Stick
Grüße
Dirk
Zuletzt geändert von Dirk am Mi 16. Sep 2020, 13:09, insgesamt 1-mal geändert.
nein, aber jede Ändereung an der EN-Version die auch in die anderen Sprachversionen fließt, muss dort genauso getestet werden wie in der Ursprungsversion. Aus (sehr) vielen Gründen ist das nicht möglich, daher werden (waren) die NLS-Varianten von ArcaOS (und eCS) schon immer Bananen-Software.
Die Art und Weise wie die NLS-Versionen bei ArcaOS (und seinerzeit bei eCS) erstellt werden ist nicht nur maximal veraltet, sondern auch noch unsäglich schlecht, was an mangelnden Ressourcen liegt, die IBM damals noch hatte.
Der grundsätzliche Aufwand das mit der Übersetzung umzustellen ist übrigens vertretbar. Ich habe seinerzeit für die eCS 2.2 keine 2 Tage gebraucht um bei der englischen Ursprungs-Version alles "Oberflächliche" sowie die mitgelieferten Programme einzudeutschen.
Benutzt habe ich dafür die vorhanden (bzw. bereits neu übersetzten) Sprachdateien, die Binaries wurden, soweit möglich, aus der Ursprungsversion übernommen, die Kommandozeile habe ich englisch gelassen. Damit war man immer top-aktuell und musste nur bei jeder neuen Beta mit einem Rexx-Script alles eindeutschen und das ISO bauen. Ging auch mit den Vorversionen schon so.
Aber warum einfach, wenn's auch kompliziert geht, ArcaNoae hat ja (ebenso wie Mensys) offensichtlich genug Geld und Ressourcen um die Übersetzung maximal umständlich umzusetzen.
Das Argument, das man keinen Support bekommt, wenn man nicht diesen schwachsinnigen Weg der Erstellung der NLS-Versionen geht ist übrigens sinnfrei. Wenn es einen Fehler in der DE-Version gibt, sollte der in der praktisch identischen EN-Version reproduzierbar sein und damit bekommt man "Unterstützung", wenn überhaupt.
Grüße,
Thorolf
Thorolf
Thorolf, das erlebe ich anders.
In der Tester-Gruppe werden alle NLV-Versionen neben der EN-Version zum Test als BETA angeboten und die DE-Tester sollen genau die gleichen Sachen testen, wie die EN-Tester in der EN-Version.
Sobald die NLV-Version offiziell erst einmal ausgeliefert ist, wird es für diese genauso Support geben, wie für die englische. Was wäre das sonst für ein Produkt?
Hmm.. wenn es keine IBM-Ressourcen mehr gibt, ist doch klar, warum alles "manuell" übersetzt werden muß. Oder verstehe ich das falsch? (Auch waren die IBM-DE-Übersetzungen nicht immer wirklich sinnhaft. Beispiele gefällig?
"DHCP-Lease time" --> DHCP Zugangszeit (W0Ot? Das hat doch nichts mit Zugang zu tun!)
Netzwerk-Route --> Leitweg (Was hat das zu bedeuten? Wüßte man es nicht besser, könnte man annehmen, daß es mit google translate übersetzt ist...)
Nene, vieles davon sollte man echt mal neu machen. So.. daß man auch versteht, was das Programm von einem will.. und nicht mit obskuren Übersetzungen, sondern mit begreifbaren Worten, wie sie sich auch in anderen Betriebssystemen durchgesetzt haben. Und nein, da ist nicht nur das aus Redmont gemeint. : ]
In der Tester-Gruppe werden alle NLV-Versionen neben der EN-Version zum Test als BETA angeboten und die DE-Tester sollen genau die gleichen Sachen testen, wie die EN-Tester in der EN-Version.
Sobald die NLV-Version offiziell erst einmal ausgeliefert ist, wird es für diese genauso Support geben, wie für die englische. Was wäre das sonst für ein Produkt?
Hmm.. wenn es keine IBM-Ressourcen mehr gibt, ist doch klar, warum alles "manuell" übersetzt werden muß. Oder verstehe ich das falsch? (Auch waren die IBM-DE-Übersetzungen nicht immer wirklich sinnhaft. Beispiele gefällig?
"DHCP-Lease time" --> DHCP Zugangszeit (W0Ot? Das hat doch nichts mit Zugang zu tun!)
Netzwerk-Route --> Leitweg (Was hat das zu bedeuten? Wüßte man es nicht besser, könnte man annehmen, daß es mit google translate übersetzt ist...)
Nene, vieles davon sollte man echt mal neu machen. So.. daß man auch versteht, was das Programm von einem will.. und nicht mit obskuren Übersetzungen, sondern mit begreifbaren Worten, wie sie sich auch in anderen Betriebssystemen durchgesetzt haben. Und nein, da ist nicht nur das aus Redmont gemeint. : ]
Zuletzt geändert von Cif am Fr 18. Sep 2020, 23:44, insgesamt 1-mal geändert.
das habe ich nicht bestritten.
Aber ArcaNoae muss damit _jede_ NLS-Version extra unterstützen, weil die sich alle von der englischen Unterscheiden und auch untereinander. Also nicht nur in den Sprach-Dateien, sondern unterschiedliche Binaries, DLLs usw.
Das macht bei den gegebenen Ressourcen einfach keinen Sinn!
Ich sage auch nicht, das man die IBM-Übersetzungen nicht verbessern könnte, aber man sollte die NLS-Versionen alle ausgehend von einer ArcaOS-Version aufbauen, nämlich der englischen die halbwegs ordentlich gepflegt und getestet wird.
Und wenn sich dann am Ende nur die Sprachdateien der Oberfläche und der Programme unterscheiden, sind nicht nur die Übersetzungen viel schneller gemacht, sondern der Support auch relevant geringen.
Theoretisch bestünde dann auch die Möglichkeit die Sprachversion nachträglich zu ändern!
Grüße,
Thorolf
Thorolf
JETZT habe ich es auch verstanden. : ]
Aber wird das bei den allermeisten OS/2-Anwendungen nicht eh über eine .NLS-Datei gemacht?
Also die Binaries sind gleich, und suchen im selben Pfad eine .NLS-Datei. Je nach Umgebungsvariable (Config.SYS) "SET LANG=" (bei mir de_DE_EUR), wird dann die entsprechende Sprache aus der NLS gelesen und in dem Binary angezeigt. - So hatte ich das Konzept verstanden.
Somit sind es doch eigentlich die selben Binaries, und es werden schlicht andere Captions aus der NLS gelesen. Oder täusche ich mich da? *kopfkratz*
Aber wird das bei den allermeisten OS/2-Anwendungen nicht eh über eine .NLS-Datei gemacht?
Also die Binaries sind gleich, und suchen im selben Pfad eine .NLS-Datei. Je nach Umgebungsvariable (Config.SYS) "SET LANG=" (bei mir de_DE_EUR), wird dann die entsprechende Sprache aus der NLS gelesen und in dem Binary angezeigt. - So hatte ich das Konzept verstanden.
Somit sind es doch eigentlich die selben Binaries, und es werden schlicht andere Captions aus der NLS gelesen. Oder täusche ich mich da? *kopfkratz*
Ich weiß, was Du meinst. Nebenbei: Es gibt keine einheitliche Methode. Für die neueren Komponenten besteht das Problem auch nicht so, aber ...
- Bei dem, was IBM hinterlassen hat, gibt es für jede Sprachversion unterschiedliche Stände. Während frühere Versionen noch sprachenmäßig umfangreicher ausgestattet sind, ist das bei den letzten nicht mehr der Fall. Damit war die Basis für eCS und für ArcaOS bei jeder Sprache verschieden, auch wenn einige vielleicht auf ähnlichem Stand waren.
- Solange an diesen Diskettenimages unter OS2IMAGE festgehalten wird, kann es keine gemeinsame Basis für alle Sprachen geben. IBM hat nämlich für verschiedene Sprachdateien unterschiedliche Diskettenimages als Quelle gewählt. Nur haben wir jetzt, anders als IBM, nichts weiteres als diese Images als Quelle, nicht die Originalquellen.
- Die eCS- und ArcaOS-Dialoge wurden mit einer speziellen Version des Dialogenhancers verbessert. Das, was anschließend in die Nachbearbeitung geflossen ist, ist aus Sicht der Vereinheitlichung hinderlich: Jetzt sind Kontrollelemente unterschiedlicher Sprachen verschieden lang, damit der jeweilige Text hineinpasst, zum Glück bisher nur sporadisch.
Dazu kommt noch, dass erstmal sichergestellt werden muss, dass alle Änderungen bei der englischsprachigen Version auch bei den anderen angekommen ist. Beides könnte entfallen, wenn alles endlich vereinheitlicht werden würde.
Ich meine damit: Erstellen einer anderen Quelle als OS2IMAGE. (OS2IMAGE muss sicherlich aus Lizenzgrund mit angeboten werden.) Ergänzen dieser Quelle um die anderen Komponenten, alles auf en_US. Dann für die unterschiedlichen Sprachen: Austausch (Kompilieren/Linken) nur der übersetzten Sprachdateien. Die Funktionalität bleibt erhalten. Sollte ein Text irgendwo nicht passen, dann wird er entweder geküzt oder das Kontrollelement in der en_US-Version vergrößert. Bei finnisch (ist glaub ich 2,5 mal länger als englisch) muss wohl vieles angepasst werden, aber da kommen wir erstmal nicht hin.
Noch ein Detail zu den Dialogen (DIALOG.ZIP): Ich hatte bei eCS die deutschen EPM-Dialoge ganz sinnvoll weiterbearbeitet, bevor ich festgestellt hatte, dass beide Versionen (en und de) bereits schon ordentlich Unterschiede hattem, was die Dimensionen der Kontrollelemente angeht. Die en-Version hatte viel mehr Fixes eingebaut. Danach hatte ich aus Verzweiflung erstmal die englischen reinkopiert, um dann diese neu zu übersetzen (natürlich dann mit den alten). Nachdem das wieder rückgängig gemacht wurde, war die Sache für mich endgültig gestorben. Nebenbei: Ob alle Dialoge den Schließen-Button brauchen, darüber lasse ich ja noch mit mir reden. Das war eine Veränderung. Sonst waren es offensichtliche Fehler bei der Anordnung der Kontrollelemente oder missverständliche Texte, auch in der englischsprachigen Version.
Zuletzt geändert von aschn am Fr 2. Okt 2020, 20:05, insgesamt 4-mal geändert.
Andreas Schnellbacher
leider irrst Du dich da gewaltig.
Es gibt zwar NLS-Dateien (.MSG), aber weil von IBM alle NLS-Versionen von OS/2 unabhängig von einander erstellt wurden, waren die auch auf Binär-Ebene zu relevanten Teilen unterschiedlich. So hatte vielleicht die englische Variante eine andere Version von xcopy, IFS, andere DLL-Versionen oder sonst was. Und das galt auch zwischen den NLS-Versionen untereinander.
Man hatte also am Ende 10 verschiedene OS/2-Versionen zu unterstützen (keine Ahnung wie viele NLS-Versionen es seinerzeit gab), die sich im Zweifelsfall unterschiedlich verhielten, v.a. war eigentlich immer nur die englische Version Top-Aktuell, alle anderen wurde mehr oder weniger gut nachgepflegt.
Und deshalb war die Übersetzungsarbeit schon bei der eCS der letzte Dreck und ArcaNoae macht genauso weiter und haben wieder nichts (aus den Fehlern anderer) gelernt
![Traurig :-(](./images/smilies/icon_e_sad.gif)
Grüße,
Thorolf
Thorolf
Oha, noch schlimmer als ich dachte. (IMO: Umso mehr Zeit das neu zu machen.)
Andreas Schnellbacher
- Prof. Knox
- Beiträge: 100
- Registriert: Mi 6. Aug 2014, 16:34
Hallo/2,
nur so am Rande, meint Ihr nicht, daß eine "kleine" Eindeutschung auch schon vielen reicht? Also alle Programme auf deutsch die es auf deutsch gibt, gleiches für Hilfen und ansonsten nur die WPS umbenennen und das eigentliche System englisch belassen.
Es gab da mal ein kleines Tool namens ANdeutsch_os2lip-24.exe welches dieses tat. Mit der aktuellen Version geht es leider nicht mehr. Eine richtige, komplette, schöne, deutsche Version ist natürlich besser (wenn die Ressourcen dafür da sind).
nur so am Rande, meint Ihr nicht, daß eine "kleine" Eindeutschung auch schon vielen reicht? Also alle Programme auf deutsch die es auf deutsch gibt, gleiches für Hilfen und ansonsten nur die WPS umbenennen und das eigentliche System englisch belassen.
Es gab da mal ein kleines Tool namens ANdeutsch_os2lip-24.exe welches dieses tat. Mit der aktuellen Version geht es leider nicht mehr. Eine richtige, komplette, schöne, deutsche Version ist natürlich besser (wenn die Ressourcen dafür da sind).
Mit freundlichen Grüßen
Prof. Knox
Prof. Knox
Auch dafür schon? Das gab es von eCo bereits für eCS. Rechtens war das nicht, weil unsere Beitraäge zu eCS waren sicherlich proprietär. Natürlich würde ich das untertsützen, auch wenn ich LIP nie ausprobiert hatte. Dieses eCoMarket und wie das Mensys aufgezwungen wurde hatte mich damals von diesen Produkten abgehalten.
Andreas Schnellbacher
Oha! Das ist ja wirklich sehr ungünstig.
Das hätte man doch MIT SICHERHEIT viel einfacher implementieren können. :o
Hmm. Wenn ihr von "neu machen" sprecht, ist j die Frage, wie genau könnte man vorgehen, damit es auch lizenzmäßig klargeht.
Auch ist die Frage, warum alle immer diesen Fehler machen. Das könnte doch darauf hindeuten, daß es nicht anders geht, wei lBM diese Vorgabe gemacht haben könnte. Reine Spekulation, freilich.
Also wenns nach mir geht, dann alles umstellen auf diese NLS-Dateien, und Binaries nur einmal für alle kompilieren. - Und dann alle neuen Texte entsprechend kürzen, daß der verfügbare Darstellungsplatz ausreicht.
Das dürfte auch ein ENORMER Aufwand sein.. allerdings haben wir ja leider die Quellen nicht, auf denen alles basiert :/
Oder wir machen einfach so weiter wie jetzt, übersetzen aber nur (ja GERADE) die Dialoge und Anwendungen, aber nicht die zig Readme-Dateien und IPFs. Die halten "nur unnötig auf", und kein Mensch guckt in die Hilfen. Und wenn doch, dann reichen auch die Englischen.... jedenfalls mir. :>
Andere sehen das bestimmt anders. Ich kenne genug Leute, die GERADE die Hilfen übersetzt sehen wollen. Für diese ist das ein wichtiges Kaufkriterium. Alles muß DE sein, damit man sich belesen kann.
Aber rein von der Empfindung hätten alle Anwendungen und das Betriebssystem an sich längst fertig übersetzt sein können, aber diese ganzen Readmes und Hilfedateien, die eh keiner liest, halten ENORM auf, und sei es nur der Syntax wegen.
Das hätte man doch MIT SICHERHEIT viel einfacher implementieren können. :o
Hmm. Wenn ihr von "neu machen" sprecht, ist j die Frage, wie genau könnte man vorgehen, damit es auch lizenzmäßig klargeht.
Auch ist die Frage, warum alle immer diesen Fehler machen. Das könnte doch darauf hindeuten, daß es nicht anders geht, wei lBM diese Vorgabe gemacht haben könnte. Reine Spekulation, freilich.
Also wenns nach mir geht, dann alles umstellen auf diese NLS-Dateien, und Binaries nur einmal für alle kompilieren. - Und dann alle neuen Texte entsprechend kürzen, daß der verfügbare Darstellungsplatz ausreicht.
Das dürfte auch ein ENORMER Aufwand sein.. allerdings haben wir ja leider die Quellen nicht, auf denen alles basiert :/
Oder wir machen einfach so weiter wie jetzt, übersetzen aber nur (ja GERADE) die Dialoge und Anwendungen, aber nicht die zig Readme-Dateien und IPFs. Die halten "nur unnötig auf", und kein Mensch guckt in die Hilfen. Und wenn doch, dann reichen auch die Englischen.... jedenfalls mir. :>
Andere sehen das bestimmt anders. Ich kenne genug Leute, die GERADE die Hilfen übersetzt sehen wollen. Für diese ist das ein wichtiges Kaufkriterium. Alles muß DE sein, damit man sich belesen kann.
Aber rein von der Empfindung hätten alle Anwendungen und das Betriebssystem an sich längst fertig übersetzt sein können, aber diese ganzen Readmes und Hilfedateien, die eh keiner liest, halten ENORM auf, und sei es nur der Syntax wegen.
Das macht bei Ressourcen nichts. Dazu gehören normalerweise z.B. Dialoglayouts, Bitmaps, Accelerator Keys und auch Texte.Cif hat geschrieben: ↑Fr 2. Okt 2020, 22:30 Also wenns nach mir geht, dann alles umstellen auf diese NLS-Dateien, und Binaries nur einmal für alle kompilieren. - Und dann alle neuen Texte entsprechend kürzen, daß der verfügbare Darstellungsplatz ausreicht.
Das dürfte auch ein ENORMER Aufwand sein.. allerdings haben wir ja leider die Quellen nicht, auf denen alles basiert :/
Die lassen sich extrahieren, mit Martin Lafaix' RDC dekompilieren, ändern und danach mit RC kompilieren und danach wieder linken. Hört sich aufwendiger an als es ist.
Seh ich auch so. Das ganze ist leider längst entschieden. Nichts mehr zu machen, würd ich sagen.Cif hat geschrieben: ↑Fr 2. Okt 2020, 22:30 Oder wir machen einfach so weiter wie jetzt, übersetzen aber nur (ja GERADE) die Dialoge und Anwendungen, aber nicht die zig Readme-Dateien und IPFs. Die halten "nur unnötig auf", und kein Mensch guckt in die Hilfen. Und wenn doch, dann reichen auch die Englischen.... jedenfalls mir. :>
Die müssten langsam so alt sein, dass sie ohne Hilfe sowieso kaum noch was hinbekommen. (Kann ich mir schon erlauben, weil ich selbst keine 10 Jahre Arbeitsleben mehr nachhab und auch von meinem Gesundheitszustand ausgehe.) Ausnahmen gibt's. Aber wie gesagt, das ist entschieden.
Ich erinnere noch, dass sich Thorolf damals immer unverständlich darüber geäußert hatte, dass ausgerechnet das Installationsprogramm vorrangig übersetzt wurde. Das ist eine Komponente, die nur genau 1x benutzt wird. Den Sprung von 1.2r aufwärts hatte ich damals vollständig übernommen und musste ihm rechtgeben. Es gibt wirklich sinnvolleres.
Nochmal zum Anspruch perfekte Sprachversionen auszuliefern: Ich halte es für illusorisch anzunehmen man könne mit so wenig beteiligten den damals risigen IBM-Apparat dafür ersetzen. Besser esrtmal nur das nötigste und so gut es geht und dafür frühzeitig Shippen!
Andreas Schnellbacher
- Frank Wochatz
- Beiträge: 1112
- Registriert: So 22. Dez 2013, 22:04
- Wohnort: Berlin
- Kontaktdaten:
Hallo allerseits,
sorry for Offtopic:
Gruß
Frank
sorry for Offtopic:
gibt es denn dafür unter OS/2 Anwendungen? Bzw. eine Möglichkeit, an die ausgelesenen Daten zu kommen?Dirk hat geschrieben:
Scanner:
- Honeywell 1400g
- CipherLab 1560P (cordless)
Gruß
Frank
Vielleicht hiermit: gImageReader als GUI für TesseractFrank Wochatz hat geschrieben: ↑Di 6. Okt 2020, 18:19 gibt es denn dafür unter OS/2 Anwendungen? Bzw. eine Möglichkeit, an die ausgelesenen Daten zu kommen?
Andreas Schnellbacher