fluent
mongodb-vapor

fluent | mongodb-vapor | |
---|---|---|
4 | 2 | |
1,549 | 40 | |
1.1% | - | |
2.4 | 0.0 | |
about 2 months ago | almost 2 years ago | |
JavaScript | Swift | |
Apache License 2.0 | Apache License 2.0 |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
fluent
-
Show HN: Open-source React library to translate apps without rewriting code
I think modern Japanese is LTR, but besides that - I believe the project you worked in the past solves an important problem.
Besides pluralization (and e.g. Arabic having 6 forms zero/one/two/few/many/other), turned out number internationalization and currency conversion are big next challenges the community wants to address next.
> create ICU compliant JSON.
I think this is an excellent idea. I have a feeling in the future we will need ICU v2.0, sort of, but unfortunately it's an extremely hard problem and the probability to fail is pretty high (looks like project fluent is not actively maintained anymore: https://github.com/projectfluent/fluent)
- Fluent: A localization system for natural-sounding translations
-
Use YouTube to improve your English pronunciation
Tried BoldVoice right now and almost immediately hit a bit of awkwardness: “Tomorrow, we’ll work on Practice your consonant skills”. Usually I wouldn’t complain about this sort of thing, but in a language learning app it seems unfortunate. (Mozilla’s Project Fluent[1] was built to handle these situations in a localization setting, but you can probably get away with something much simpler.)
[1] https://projectfluent.org/
-
Internationalization best practices for front-end developers
Hi! Thank you for your critique!
> 1) “Your knight has killed a dragon with a crossbow”
We have a proposal for dynamic references to address this problem - https://github.com/projectfluent/fluent/issues/80 - it's non-trivial but I hope we'll see it solved in Fluent and/or in MessageFormat 2.
> 2) The parser is extremely sensitive
True. It's on purpose. We wanted to start with strict and loosen, rather than the opposite.
> 3) The input files mandate a weird arrangement of new lines for even the simplest branching
Same as above.
> 4) The documentation is too Spartan to know what happens in edge cases.
We're a small team :)
> It heralds itself to be the saviour of all i18n, but it’s literally worse than the mess that came before it.
I'm sorry to hear it doesn't work for you. I'm relieved that your criticism is seems more subjective except of one missing feature that no other l10n system has as of yet.
mongodb-vapor
-
Using Swift, Vapor, and MongoDB for applications
mongodb-vapor library
-
MongoDB and Swift Vapor Integration
Check it out on github. Documentation for the Swift Driver here.
What are some alternatives?
pot-desktop - 🌈一个跨平台的划词翻译和OCR软件 | A cross-platform software for text translation and recognition.
swift-nio - Event-driven network application framework for high performance protocol servers & clients, non-blocking.
sqlite-orm-swift - 🧡 Easy to use SQLite ORM library written with love and Swift
fluent - Vapor ORM (queries, models, and relations) for NoSQL and SQL databases
RVS_Generic_Swift_Tool
MongoKitten - Native MongoDB driver for Swift, written in Swift [Moved to: https://github.com/orlandos-nl/MongoKitten]
