Localization is the process of adapting, translating and customizing a product for a specific locale or cultural conventions. Localization distinguishes a good web front end from a truly successful one. Today English is a priority language to be learning to use computers. Having Localization we can gain benefits such as, no need to local users to learn English first, Reduce amount of training and localization brings additional value. To improve localization community of volunteers needs to get together and first establish a guiding set of terms to guarantee accurate and consistent translation. Community is the strongest part for an Open Source project. Translation process can be improved by making sure that efforts in translations are consistent and structured. So the lots of local users can enjoy KnitWeb and hopefully become a part of the community.
How Localization work on KnitWeb
.properties files (en.properties, ge.properties): These files contain the translations of strings used in the KnitWeb. Each line is the translation of a single string in “name=value” format; name is an identifier for this string, It is used to map the string; value is the translation of the string in particular language.
#Inputs input_port=Port input_machine=Maschine:
#Inputs input_port=කවුළුව input_machine=යන්ත්රය:
locales.ini : locales.ini includes which is the default language in case app does not support current language, what type of other locales KnitWeb supports and the location of the each translated file.
An exception is an error that happens during the execution of a program. It is important to have exception handler in KnitLib to handle and deal with errors automatically. Many standard libraries define their own exceptions to report errors that may occur in functions they define. Depending on the kind of error in knitlib (“communication error”, “pattern not found error”, etc.. ). The exception handler module in the knitlib can handle the exception and the knitlib can be continued afterwards with the previously saved data.
Define exceptions as classes
Exception can be defined as classes which do any other class can do, but are usually kept simple, often only offering a number of attributes that allow information about the error to be extracted by handlers for the exception. When creating a library like KnitLib which can raise several distinct errors, a common practice is to create a base class for exceptions and subclass that to create specific exception classes for different error conditions.
Having test cases is very important especially for a library like KnitLib because using test cases; we can clearly test particular fields. In KnitLib, test cases show the information of how the KnitLib should be checked. Also test cases help for new contributors to understand about the KnitLib.
There are several test cases for the current KnitLib implementation such as tests on ayab communication, tests on ayab image, tests on command line interface, tests on KnitPat module and tests on knitting plugin.
For an example in ayab communication there are several important functions have been tested. Test on closing serial port communication, test on opening serial port with a baud rate of 115200 which ayab fits, tests on sending start message to the controller, tests on sending line of data via serial port and tests on reading line from serial communication. Most of these tests have been done using mock tests. Mock is a python library to test in python. Using mocks we can replace parts of our system with mock objects and have assertions about how they have been used. We can easily represent some complex objects without having to manually set up stubs as mock objects during a test.
It is very important to improve further test cases on the KnitLib because with the help of good test cases we can guarantee that the KnitLib’s features and functionalities should be working great.
Hi everyone, I’m Shiluka Dharmasena, Computer Science and Engineering undergraduate from University of Moratuwa, Sri Lanka. Thanks very much for this great opportunity to get involves in FOSSASIA open source project and I’m keen to give my fullest contribution to the FOSSASIA. For GSoC 2015, I am developing a library to support knitting machines. It’s great to work with FOSSASIA team under awesome mentors Mario Behling and Christian Obersteiner. This is the Initial suggestions for the project.
Library to support knitting machines
Basic abstraction of the library to create library as separate layers
Serial communication : open, configure, read and write to serial port
Machine definitions : machine initialization, load to machine, save from machine
Image handling functions : memory allocation, read image file, setter and getter for image pixels
File handling functions : read / write access
Common utility functions
Add dependencies for the library
There are several dependency libraries which ayab has such as pillow, pyserial, wsgiref, fysom and yapsy with relevant versions. These dependencies should be added to the library.
Functions for the library
For access hardware directly
* Identify existing libraries to interface with hardware
* Use libraries to deal with serial ports
* Ability to get all the functions via library (for an example functions in ayabControl.py and add more functions to support in more machines)
* Ability to send QT signals
Emulate file formats
* Create functions to emulate file format
Add Arduino support
Installation should be well documented in step by step. Additionally I suggest to add GUI based installation with usability improvements with standard installation procedures.
* Installation on Linux (32bit, 64bit)
* Installation on Windows (32bit, 64bit)
Tests on the library
Use a python test framework like unittest to test the python library. It supports test automation and aggregation of the tests into collection.
Documentation of the library
Documenting Class definitions, methods definitions and links to the given source codes.