Translation and more for an existing Symfony project.
Budget: €750 – €1,500 EUR
This project is a filling plant for air. Similar to a gas station
First Point:
We need for an already existing Symfony project, we need the option of integrating a translation.
We are happy to discuss details in the chat
1. The project should be translated into several languages (German, English, French, Italian)
2. This project has a backend for administrators and operators. (Administrator had full access to all tables and settings. The operator may only see his settings and his table entries)
3. The administrator should be able to define a primary language for each operator (all customers of the operator and the operator themselves have then preselected this language)
4. The operator should be able to adapt the language for each of his customers.
5. The administrator should be able to adapt the language for both operators and customers.
6. A separate subpage should be created for the administrator in which the words and sentences from the backend and frontend of the website are listed. Here he can then enter the translations for all languages.
7. Ranking list of languages: If no language has been stored for the customer, he takes the language from the operator, if no language has been stored with the operator, he takes German
1. Administrator defines the language for the operator. (Standard language, if no language has been specified: German)
2. Operator defines the language for his customers. (Default language of the administrator if no language has been specified)
3. Standard language of the customer, if no language has been specified).
Second Point:
The system is to be expanded to include several filling variants. Here are the relevant requirements.
There is a backend and a frontend.
The administrator and the operator can login in the backend.
The customer can only register for the filling using his customer card in the front end
The filling station is currently developed in such a way that air can be filled with a maximum amount of 200 bar.
An extension is to be developed here.
1. In the backend, it should be possible to select what can fill each station.
2. This view should be designed as a table
3. The filling variants should be modular (add and delete possible)
Options in the table:
1. Name (given values because each needed to be translated)
2. Pressure (Fill 200 or 300 bar)
3. Sensor_input (A0,A1,A2,A3),
4. price
5. special price
6.
The process in the backend and while filling a customer:
1. The setting which variants the station can fill should be specified in the backend (administrator and operator).
- price: operator
- special price: operator,
- Station Fill functions: Administrator
2. If the customer fills a bottle, the settings are transferred to the hardware via JSON file before the actual filling. The filling variant must be added here.
3. From here on I take over the programming of the hardware.
Front end: (what the customer sees when he wants to fill a bottle.)
1. A tile view should appear in front of the "Filling" view. By selecting a tile, the customer should then be able to choose his filling variant (e.g. 200bar, 300bar). Of course, only the filling variants that the respective station offers should be listed here. The station is currently being transmitted via the URL.
First Point:
We need for an already existing Symfony project, we need the option of integrating a translation.
We are happy to discuss details in the chat
1. The project should be translated into several languages (German, English, French, Italian)
2. This project has a backend for administrators and operators. (Administrator had full access to all tables and settings. The operator may only see his settings and his table entries)
3. The administrator should be able to define a primary language for each operator (all customers of the operator and the operator themselves have then preselected this language)
4. The operator should be able to adapt the language for each of his customers.
5. The administrator should be able to adapt the language for both operators and customers.
6. A separate subpage should be created for the administrator in which the words and sentences from the backend and frontend of the website are listed. Here he can then enter the translations for all languages.
7. Ranking list of languages: If no language has been stored for the customer, he takes the language from the operator, if no language has been stored with the operator, he takes German
1. Administrator defines the language for the operator. (Standard language, if no language has been specified: German)
2. Operator defines the language for his customers. (Default language of the administrator if no language has been specified)
3. Standard language of the customer, if no language has been specified).
Second Point:
The system is to be expanded to include several filling variants. Here are the relevant requirements.
There is a backend and a frontend.
The administrator and the operator can login in the backend.
The customer can only register for the filling using his customer card in the front end
The filling station is currently developed in such a way that air can be filled with a maximum amount of 200 bar.
An extension is to be developed here.
1. In the backend, it should be possible to select what can fill each station.
2. This view should be designed as a table
3. The filling variants should be modular (add and delete possible)
Options in the table:
1. Name (given values because each needed to be translated)
2. Pressure (Fill 200 or 300 bar)
3. Sensor_input (A0,A1,A2,A3),
4. price
5. special price
6.
The process in the backend and while filling a customer:
1. The setting which variants the station can fill should be specified in the backend (administrator and operator).
- price: operator
- special price: operator,
- Station Fill functions: Administrator
2. If the customer fills a bottle, the settings are transferred to the hardware via JSON file before the actual filling. The filling variant must be added here.
3. From here on I take over the programming of the hardware.
Front end: (what the customer sees when he wants to fill a bottle.)
1. A tile view should appear in front of the "Filling" view. By selecting a tile, the customer should then be able to choose his filling variant (e.g. 200bar, 300bar). Of course, only the filling variants that the respective station offers should be listed here. The station is currently being transmitted via the URL.