Opral
Fink Vision 24 #677
Replies: 3 comments 6 replies
-
|
Good write-up! I am wondering what can be achieved in 2023 of the laid out points. Markdown support seems to be closed but requires a fundamental addition and/or changes to the I thought about extending/changing the editor to have "views". Views are triggered by the lowest common denominator of any content: The file (format). For example, a view (extension/plugin) can be written for the But, what I laid out above i.e. views is essentially a new product :D We should discuss in Amsterdam what our product and business goals are for 2023 and 2024. For now, let's nail Messages first. |
Beta Was this translation helpful? Give feedback.
-
|
@ivanhofer this is another reason why I am pushing hard against node dependencies. I am sure that the inlang editor will support "code unrelated" content and might even transform it into VSCode for content. Node dependencies would hurt those audiences. |
Beta Was this translation helpful? Give feedback.
-
|
I never said we should use node dependencies! In the end everything get's fetched from |
Beta Was this translation helpful? Give feedback.
-
|
I totally agree with that. Different content needs different viewers with a fitting editing flow. This would bring inlang into the realm of a CMS. But then the question is whether a WYSIWYG view of the entire page and editing via a browser extension might be interesting. Maybe I'm a little influenced by Vercel's visual editing. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome to read what's ahead 😍 I totally agree with what @samuelstroschein wrote above, the scope seems rather big and we have to keep in mind that not only the editor has to envolve around topics like (only to pick one out of the list) better collaboration, but the whole "the next git" has too. Like @araknast said, really seamless collaboration for example only would work with streamed repo updates. Also, we are already starting out and our user number just started out growing. This means there are a lot of repositories which can benefit from our current implementation and together with those users, we would have the best base layer of building a super useful products for their needs. Without (a lot of) users, it would be dangerous to go into technical depth without somebody using it and at the same time making the product more complex and harder to explain. Potentially: More docs. More setup. More bugs. etc. Let's focus on nailing messages and building out a big plugin system for tools like |
Beta Was this translation helpful? Give feedback.
-
|
Git-wise, most of these features should be able to be implemented using functionality which already exists in isomorphic-git. Most of the work would be on the frontend, so the total amount of work would depend mostly on that. The main exception which would require extensive modification to git is streaming repository updates, which I agree would be extremely useful to users. This is one aspect of my more detailed idea of "the next git" which I hope to share at some point later once it is more fleshed out. Whether this would be accomplish-able within the year depends on the complexity of other git-related tasks, as well as our server implementation. |
Beta Was this translation helpful? Give feedback.
-
|
I am excited for your notes on the git vision. Streamable repos/lazy loading of repos is definitely a blocker right now to make the inlang editor useful for larger repositories. |
Beta Was this translation helpful? Give feedback.
-
|
@NiklasBuchfink Can you update this into Vision 24? Maybe share a quick update on what was achieved in 2023? |
Beta Was this translation helpful? Give feedback.
-
|
The above description now feels like a Vision 2025. We have laid the foundations for this, but it is more work than expected. Update (Jan '24)
Rich text & other media
Review & Merge
Collaboration
All functions that require a storage solution and accounts will probably not become relevant until 2025:
We still have a long way to go and there is still a lot of groundwork to do. We are constantly evaluating what will be most relevant for our target group next and develop the feature accordingly. This seems to be the right approach as our user group grows with us and we derive the right features based on real use cases. |
Beta Was this translation helpful? Give feedback.
-
The Vision
inlang uses Git as its database and infrastructure. This approach offers many advantages, such as eliminating handoffs between developers and translators and synchronization between databases. We want to make the development workflow accessible to non-technical people and build a next-gen software infrastructure for collaboration.
Goals of this discussion
Challenges
The following are initial thoughts to future benefits, which challenges exist and how they could be addressed.
Rich text & other media
The editor should not only support strings, as all types of media need to be updated and localized.
Markdown support
Since a lot of documentation is written in Markdown and it can be used as a way to edit rich content on a web page, Markdown should be supported. The offers the added benefit that the inlang editor can also be used as a CMS for editing and translating rich content.
From a user experience perspective, a preview of the content with context of the page would be the best. Access to the repository can provide this context. Theoretically, a WYSIWYG editor could also be provided within the real web page, which could be implemented via a Chrome extension.
Images, Audio, Video
Images, audio and video are content that is often stored outside of a Git repository. Deploying assets very often involves a long handoff process. In the editor, there should be a preview to view the current content and to evaluate changes. This is directly related to how the review and merge process could be handled. AI content creation functions could also come in handy at this point to create localized media.
Review and merge changes
Automated merges
To avoid a huge additional workload for maintainers due to the increase of new, non-technical users, changes accepted in the editor should be automatically published by a CLI and return good error messages in case of errors.
History and versioning
A big advantage of Git is the versioning of the data. To keep the history human readable, it is important to create meaningful commit messages. This can be achieved by providing context for actions in the frontend when commits or pull requests are created. As errors occur and changes are accidentally overwritten, sooner or later it must be possible to view and restore older changes via the editor.
Handling notifications
To keep users up to date, there must be a way to receive notifications. Perhaps this can be realized with little effort at first by matching the timestamp of a user's last login. Accordingly, the corresponding notifications are displayed. Again a user interface is needed for review processes, exchange via comments and merging of content.
Collaboration
Comments
Comments are the most common form of asynchronous collaboration. To make these inside the editor possible, a simple storage is required to save the data. Role management should be done directly inside of git.
Subscriptions
Streaming updates from the repository to the client app is very useful for collaboration and expected behavior in today's app. A higher refresh rate of customer data prevents working with old data, doing work that has already been done, and results in fewer merge conflicts. Normally, a server is used for this purpose, which synchronizes and manages the data of the clients. This functionality would have to be ensured within the new Git architecture.
Note: I am trying to update the content so that it serves as a summary of this discussion.
Beta Was this translation helpful? Give feedback.
All reactions