kan02134
Joined 4 years ago
Karma
8
Submissions
15
Member since
May 21
hi
View on Hacker NewsRecent submissions
Comment · 1 year ago
Hey HN, I created Yuki-no while maintaining the official Vite Korean documentation translation project.
Translation work requires meticulous tracking of changes in the original documentation. Without this, translators might translate incorrect content or miss important sections.
Previously, we used Ryu-Cho(https://github.com/vuejs-translations/ryu-cho) for tracking. This open source tool uses GitHub Actions to register changes in the original repository as GitHub Issues in the translation repository. However, after using it for nearly two years, I identified several issues:
1. When GitHub Actions failed, all in-progress commits were lost, causing us to miss portions of the original content 2. The approach for filtering target files was very limited (based on `startsWith` string prefix comparison) 3. Inability to set labels on GitHub Issues made them difficult to distinguish from other issues at a glance 4. No way to identify whether translation-related commits were released, potentially causing premature translation of unreleased content
Yuki-no solves these problems with:
- Improved Action stability through batch processing (verified to work correctly for over 200 commits) - Automatic recovery from failures in subsequent runs - Release tracking feature - Glob pattern-based target files filtering - Custom label settings for created issues
It's currently used in:
- Official Vite Korean documentation project - Vue.js Korean documentation project - Vite documentation translation template
Example issues: https://github.com/vitejs/docs-ko/issues?q=is%3Aissue+label%...
If you're planning to start a translation project, need help with migration or configuration, or are interested in the project, feel free to reach out through GitHub issues or email me at [email protected]!
Comment · 1 year ago
Thanks for the suggestion! While I initially considered providing sample images, I realized they might not effectively convey the tool's real value, which is analyzing your personal shooting patterns.
Perhaps you could try it with some smartphone photos? Smartphone cameras typically include EXIF data, making them perfect for testing the tool. Even a few casual photos from your phone should give you a good sense of how the tool works. This way, you can experience the functionality with your own real-world images rather than pre-prepared samples.
Comment · 1 year ago
Thank you! It's really encouraging to hear this. When I shared it with a small photography community, many said this was exactly the kind of information they'd been wanting to see. It makes me feel that creating this tool was truly worthwhile, knowing it addresses a real need in the photography community.
Comment · 1 year ago
Let me share my experience. This tool helped me objectively understand which focal lengths I actually prefer. It was particularly valuable when I was considering new lens purchases. For instance, you might choose to invest in a lens that covers your most-used focal lengths, or alternatively, explore new creative possibilities with focal lengths you rarely use. I see this tool as a small compass that helps us better understand and develop our photography journey.
Comment · 1 year ago
As @nanoanderson mentioned, we use the "FocalLengthIn35mmFormat" tag from EXIF. Let me explain why: since cameras have different sensor sizes, comparing actual focal lengths directly can be misleading (https://en.wikipedia.org/wiki/Crop_factor#Introduction). By using the 35mm film equivalent, we can compare field of views across all cameras on the same scale. For instance, a 50mm lens on a crop sensor camera shows a similar field of view to a 75mm lens on a full-frame camera.
We're using the 'exifr' library for EXIF data extraction: https://www.npmjs.com/package/exifr
Comment · 1 year ago
Thank you for such insightful feedback! I should clarify that this tool was designed as a web-based solution to avoid the traditional installation or server upload requirements, aiming for maximum accessibility. While I hadn't considered a CLI approach initially, you make an excellent point about its efficiency. However, I'm still weighing the trade-off between performance and accessibility.
I completely understand your concerns about the drag-and-drop stability with thousands of files. The issue you're experiencing with Vivaldi might be related to this. Would you mind trying the file picker button instead? I've been unable to reproduce the issue on my Apple M1 MacBook with the same browser, which makes it challenging to provide an immediate fix. I apologize for the inconvenience.
Regarding EXIF extraction, we're using the 'exifr' npm library, which actually works exactly as you suggested - it only reads the beginning portion of the file to extract EXIF data, even in the browser. You can learn more about it here: https://www.npmjs.com/package/exifr
Comment · 2 years ago
Hello! There are currently many issues when creating video thumbnails in iOS Safari. While writing the article, I also came across some interesting insights. For example, did you know that the Media Fragment URI (#t=0.001) does not currently work with Blob URLs? I explain everything here!
Comment · 2 years ago
I recently needed to generate thumbnails for videos on iOS Safari. However, unlike other platforms, it often didn't work well. I tried GPT and googling... but they weren't much help. So, I had to figure out a "working version" myself. It was quite challenging, but I finally found a solution that worked!
Comment · 4 years ago
Hello everyone.
This project is a JavaScript implementation of the Bionic Reading API, distributed via npm and available in a browser or NodeJS. It supports HTML and Markdown formats, and related settings can be passed through options.
Thanks for reading.
Comment · 4 years ago
Cool. Looks great.