Here what we will do is list all the functionality that is required, without consideration as to if they are already implemented in the current Lopenling (Hasura) backend or not. The engineer will in the RFC exclude all the requirements that are already fulfilled previously.
What is being introduced?
This RFW does introduce any new technical requirements, as it focuses only on producing the front end.
What is changed?
This has two parts. One is regarding the default, which is the user not having logged in. The other is regarding when the user has already logged in.
First, regarding the user not having logged in.
Exact match search for Tibetan terms (keys)
Partial match search for Tibetan terms (keys)
Description search for any string (values)
User can input Wylie or Tibetan, Wylie will be converted to Tibetan
Whitespace, line breaks, and such will be automatically emitted from the search input string
Ability to filter search as well as results based on dictionary selection
Second, regarding the user already having logged in.
The only difference between having not logged in or have already logged in is that the former will see all the native dictionaries, but the latter will see the dictionaries they have visibility rights for.
Is This Really Necessary?
It is. There are many good reasons for why we can't continue simply by adopting the current system running on https://padma.io.
Motivation
Glossary is one of the most important and frequently used auxiliaries for translators, and is, therefore, a critical part of the Lopenling ecosystem.
Named Concepts
NA
Examples, Risks & Assumptions
Explain concretely what will manifest as a result of this RFW.
The required backend functionality.
Explain how is it different from what is already manifesting i.e. what we already have?
We don't have all the required features implemented in our current backend.
Explain what users/brands will experience as a result of this RFW. How will they feel as a result of it? How will they benefit as a result of it?
Users will be able to manage their dictionaries in a single location and access it as part of the integrated experience they are having with Lopenling.
If applicable, provide sample messages for any new messages the system will display as a result of this RFW.
This will come from the frontend side and is not relevant to this RFW.
Define what is out of scope in this request.
Everything to do with the frontend part is out of scope.
What are the data protection, privacy, and security assumptions made for this request (for example, should this be GDPR, compliant, etc)
None
Explain how this user story will be supported (i.e. customer support - if the user story fails technically, how will the user be supported).
It will not be supported.
Explain how this user story impacts revenue or billing (if applicable).
NA
State any additional risks identified as a result of this user story.
None
Success Metrics
We are able to fulfill all the requirements set forth by the frontend design in:
The only alternative would be to just adopt what we have in https://padma.io already. This anyhow is not a good approach, and this can be seen through the points already made in the above sections.
New Data
None
Business release date
The design part is to be completed post to having completed any frontend design requirements in:
Table of Contents
Housekeeping
Done
ALL BELOW FIELDS ARE REQUIRED
The Problem
Right now we have a glossary system running on https://padma.io which is based on a Python backend without a database.
User Story
The user story is described in:
This RFW will cover the backend requirements for that user story.
Request Type A/B
This RFW is Type-A.
It connects with the following RFWs:
Most importantly, it is paired with the frontend part already mentioned in the previous section:
Owner
mikkokotila
Summary
Here what we will do is list all the functionality that is required, without consideration as to if they are already implemented in the current Lopenling (Hasura) backend or not. The engineer will in the RFC exclude all the requirements that are already fulfilled previously.
What is being introduced?
This RFW does introduce any new technical requirements, as it focuses only on producing the front end.
What is changed?
This has two parts. One is regarding the default, which is the user not having logged in. The other is regarding when the user has already logged in.
First, regarding the user not having logged in.
Second, regarding the user already having logged in.
The only difference between having not logged in or have already logged in is that the former will see all the native dictionaries, but the latter will see the dictionaries they have visibility rights for.
Is This Really Necessary?
It is. There are many good reasons for why we can't continue simply by adopting the current system running on https://padma.io.
Motivation
Glossary is one of the most important and frequently used auxiliaries for translators, and is, therefore, a critical part of the Lopenling ecosystem.
Named Concepts
NA
Examples, Risks & Assumptions
The required backend functionality.
We don't have all the required features implemented in our current backend.
Users will be able to manage their dictionaries in a single location and access it as part of the integrated experience they are having with Lopenling.
This will come from the frontend side and is not relevant to this RFW.
Everything to do with the frontend part is out of scope.
None
It will not be supported.
NA
None
Success Metrics
We are able to fulfill all the requirements set forth by the frontend design in:
Conceptual Design
Whatever the above sections provide suffice.
Drawbacks
None
Alternatives
The only alternative would be to just adopt what we have in https://padma.io already. This anyhow is not a good approach, and this can be seen through the points already made in the above sections.
New Data
None
Business release date
The design part is to be completed post to having completed any frontend design requirements in: