Design & Architecture

Απ: Πολυγλωσσικότητα και Υποστήριξη Λογισμικού

Νατάσα Μανουσοπούλου — Mon, 27 Nov 2006 21:07:22 GMT

Το μεγάλο πρόβλημα στην υποστήριξη δεν είναι τόσο τα exceptions και το event log, αφού μπορείς να χρησιμοποιήσεις κωδικούς λαθών και event IDs που θα σου δίνουν ένα μπούσουλα με τη βοήθεια του εγχειριδίου σφαλμάτων Το μανίκι είναι στην καταγραφή των support calls και των FAQs, τα οποία θα πρέπει να αναφέρονται όλα στην ίδια έκδοση της εφαρμογής, κατά προτίμηση την αγγλική.

Αν θεωρήσουμε δεδομένο ότι όσοι παίρνουν τηλεφωνήματα στην υποστήριξη έχουν την εφαρμογή μπροστά τους, θα μπορούσες να έχεις ειδικές εκδόσεις για το support, όπου σε κάθε control, εκτός από το localized κείμενο να δείχνεις π.χ. σε ένα tooltip το αγγλικό κείμενο, το οποίο θα πρέπει ο supporter να καταγράφει στο CRM/bug tracking/whatever. Βέβαια στηρίζεσαι πολύ στον πατριωτισμό τους, γιατί μπορούν άνετα να αγνοήσουν τα αγγλικά και να γράψουν ό,τι θέλουν. Επίσης πρόβλημα υπάρχει και στα e-mails των πελατών, στα οποία είναι βέβαιο ότι δε θα καταγράφεται το αγγλικό κείμενο (αν έχεις το localized και μάλιστα σωστό θα είσαι υπερτυχερός).

Μπορείς να κάνεις τη ζωή όλων πολύ πιο εύκολη, αν είναι δυνατή η εύκολη εισαγωγή screenshots μέσα σε κάθε ticket ή e-mail πελάτη. Έτσι τουλάχιστον θα είναι δυνατό το ταίριασμα με βάση τη θέση των controls στην οθόνη.

Απ: Πολυγλωσσικότητα και Υποστήριξη Λογισμικού

Dimitris Papadimitriou — Mon, 27 Nov 2006 20:22:06 GMT

Τι μου θύμισες!!! Ξέρω, δεν εννοείς αυτό, αλλά δεν μπορώ να μην το παραθέσω...!

Οι περιπέτειες του Ζαχαρία Δεντοφτιάχνω wrote:

ΕΜΠ:Δηλαδή; Τι θέλετε να πείτε; Ενας κωδικός εξηγεί στο χρήστη τι συνέβη;
ΑΠΞ: Φυσικά! Κάθε εφαρμογή που ΕΓΩ προσωπικά επιμελούμαι συνοδεύεται από ένα εγχειρίδιο επεξήγησης κωδικών!
ΨΜΜ: Ναι, ναι! Και στη σχολή όταν κάναμε τις ασκήσεις βάζαμε κωδικούς σφαλμΑΟΥΤΣ!
(Το πόδι του Ζαχαρία βρήκε αυτή τη φορά το σωστό στόχο) ΕΜΠ: Εεε, κύριε Ξερόλα, τι μεγέθους είναι αυτό το εγχειρίδιο;
ΑΠΞ: (Κορδωμένος, με υπερηφάνεια υπερκαταναλωτικού κατόχου πιστωτικής κάρτας που πήρε μηδενικό ποσό χρέους στο statement του για το μήνα) Πάνω απο 100 σελίδες! Ακόμα και αν δεν έχουμε ΤΟΣΑ μηνύματα σφάλματος, βάζουμε και κάποια τα οποία δεν εμφανίζονται ποτέ στην εφαρμογή για να πιάσουμε τις 100 σελίδες! Μερικά στην τύχη.
ΕΜΠ:Και γιατί το κάνετε αυτό;
ΑΠΞ: Αααα, απλά πράγματα. Ξέρετε τι ευχαρίστηση είναι για τον πελάτη να παίρνει κάτι τόσο ΒΑΡΥ στα χέρια του; (Με θερμοκόλληση και σκληρο΄εξώφυλλο, εννοείται). Φαίνεται ωραία στη βιβλιοθήκη του, και νοιώθει οτι αξίζει τον κόπο που πλήρωσε τόσα χρήματα για την εφαρμογή. Αφήστε που ΕΓΩ έχω φτιάξει και ένα random error message generator ακριβώς για αυτό το λόγο.
συνέχεια...

Η ιδέα του dictionary είναι λίγο δύσκολη στην εφαρμογή της, καθώς δεν ταιριάζει πολύ με την λογική των exception. Π.χ. μια μέθοδος σηκώνει ένα exception, το οποίο έστω ότι έχει ένα ID. Αυτό το πιάνει μια άλλη μέθοδος και ξανασηκώνει άλλο exception με άλλο ID, ενώ το πρώτο μπαίνει σαν inner exception. Για να καταλάβει τελικά ο developer τι συνέβει ίσως (τονίζω το ίσως!) τελικά χρειαστεί όλο το exception trace. Μήπως τελικά μια λύση να ήταν στο κάθε exception να έχω μια μεταφρασμένη περιγραφή και μια επιπλέον στα αγγλικά, ίσως ακόμα και το ID που αναφέρεις εσύ Σωτήρη; π.χ.

Public Class MyException
    Inherits ApplicationException
    Private _ID As Integer
    Private _NativeMessage As String
    Public ReadOnly Property NativeMessage() As String
        Get
            Return _NativeMessage
        End Get
    End Property
    Public ReadOnly Property ID() As Integer
        Get
            Return _ID
        End Get
    End Property
End Class

Βέβαια μιλάω για exceptions για τα οποία δεν έχουν δημιουργηθεί ειδικά exception types, μια που σε εκείνα μπορείς να καταλάβεις το exception μόνο από το type name.

Απ: Πολυγλωσσικότητα και Υποστήριξη Λογισμικού

Παναγιώτης Καναβός — Mon, 27 Nov 2006 20:01:11 GMT

Για τα κουμπιά και τα labels, ο μηχανισμός localization των Winforms μπορεί να κάνει τη δουλειά. Το Event log από την άλλη, υποστηρίζει όποια γλώσσα θέλεις ... μόνο που δεν μπορείς να το χρησιμοποιήσεις έτσι μέσω .NET! Το Event Log αποθηκεύει μόνο EventIDs και παραμέτρους. Τα μηνύματα που διαβάζουμε δημιουργούνται από τον viewer χρησιμοποιώντας resource dlls. Μόνο που το .NET δεν υποστηρίζει τη δημιουργία resource dlls! Τα μηνύματα που γράφει το .NET έχουν απλά ως πρώτη παράμετρο όλο το string που διαβάζουμε μετά. Resource dlls μπορείς να φτιάξεις χρησιμοποιώντας εργαλεία της C++ και του SDK :(

Προφανώς, στην περίπτωση σου δεν αρκεί να φορτώνεις το κατάλληλο event ή exception string από τα Resources για μόνο γλώσσα. Το καλύτερο θα ήταν να αποθηκεύεις το event ID και ο viewer να εμφανίζει το κατάλληλο μήνυμα. Αλλά ...

Ένας τρόπος να διευκολύνεις λίγο την κατάσταση είναι να ορίσεις ιεραρχικά event IDs, έτσι ώστε οι admins να μπορούν τουλάχιστον να καταλάβουν τί λέει το ID. Μία άλλη λύση θα ήταν να φτιάξεις τον δικό σου viewer, ο οποίος θα διαβάζει τα event ID από το Event Log και θα τα φορμάρει ανάλογα με τη γλώσσα του χρήστη. Η ιδέα όμως μου φαίνεται παράξενη, καθώς ουσιαστικά θα ξαναγράψεις τον Event Viewer για .NET.

Απ: Πολυγλωσσικότητα και Υποστήριξη Λογισμικού

KelMan — Mon, 27 Nov 2006 19:56:51 GMT

Υποθέτω ότι τα event log events και τα exceptions θα έχουν κάποιο ID μέσω του οποίου θα μπορούσες να έχεις ένα dictionary για κάθε μία γλώσσα. Πάντως, μπορείς να κάνεις ultimate error handling ώστε να μην φτάσει ποτέ το exception στον χρήστη, δες αυτό το άρθρο μου http://www.dotnetzone.gr/cs/blogs/mkelaiditis/articles/9419.aspx

Πολυγλωσσικότητα και Υποστήριξη Λογισμικού

Dimitris Papadimitriou — Mon, 27 Nov 2006 19:45:35 GMT

Για άλλη μια φορά στο αγαπημένο μου forum στο dotΝΕΤΖone!

Έχω την τύχη να ασχολούμαι με ένα project το οποίο θα λειτουργήσει τελικά σε περισσότερες από μια γλώσσες. Τεχνικά θέματα σχετικά με τη διαχείριση των resources και την μετάφρασή τους έχουν λυθεί, σε γενικές γραμμές, χρησιμοποιώντας τα πολύ ωραία typed resources του VS 2005.
Η υποστήριξη του προϊόντος θα γίνεται από τα κατά τόπους παραρτήματα της εταιρείας για την οποία αναπτύσω το project και βέβαια η υποστήριξη θα γίνεται στην γλώσσα της κάθε χώρας. Οπότε, κάποια στιγμή το εγχειρίδιο χρήσης θα έχει μεταφραστεί, καθώς και τα exceptions, τα λεκτικά πάνω στα πλήκτρα κλπ. Η ανάπτυξη του project συνοδεύεται από ένα community server, στον οποίο θα έχει πρόσβαση το προσωπικό υποστήριξης και ανάπτυξης της εταιρείας, αλλά όχι και ο τελικός πελάτης. Επίσης υπάρχει και ένα Gemini για bug tracking. Προφανώς τόσο community server όσο στο Gemini τα θέματα θα καταγράφονται στα αγγλικά.

Θα ήθελα την γνώμη σας στο εξής: Πως θα μπορούσε να γίνει σωστή συννεόηση, όταν ο κάθε εμπλεκόμενος "τρέχει" το σύστημα στην δική του γλώσσα, οπότε τα πλήκτρα γράφουν "Αποθήκευση", "Save" ή "Save [in Bulgarian]"; Επίσης ο server θα καταγράφει τα event log σε διαφορετικές γλώσσες. Το ίδιο συμβαίνει και με τα exceptions που θα σηκώνονται. Βαβέλ!!!

π.χ. μια λύση θα ήταν να γίνει μερική μετάφραση και κάποια πράγματα να είναι μόνο στα αγγλικά, π.χ. server exceptions. Με την λογική όμως ότι ένα exception δεν ξέρεις σε πιο σημείο θα το "πιάσει" η εφαρμογή, μπορεί τελικά να φτάσει και στον τελικό χρήστη.