Somewhat related topic: anyone used something like the Luxedo to do a projection mapping? It seems like it’s more complicated and expensive but I love the idea of doing something cool to the house for Halloween and Christmas without having to lug out a ton of lights and decorations.
There are media players and graphics generators that will run on a RaspPi also. Finding a bright enough projector and sheltering it for outdoor use might be the main challenge.
Another approach might be a galvo scanned laser with DMX software to control it, though there may be safety/liability issues with that.
I‘m fascinated by these projection setups ever since I learned they’re a thing! But Jesus is the Luxedo stuff pricey?! I’d love to learn about something similar but in a kinda OSS/DIY kind of style…
I think that ideally, every project would be setup from scratch in the beginning to use t() tags or something similar to have translation keys so that setting up translations is as easy as swapping out what t() returns (from e.g. a config file or the like).
Of course, we all know that this is very rarely how projects end up getting setup especially in the early stages, and then it's just massive amounts of work to go back and set it up later.
The thing that's the most intriguing to me about what you're describing is automatically setting up translations in the build step where you auto-detect strings to translate. But looking at the site, most of it seems to be focused around the VSCode extension which will just sort of find and replace strings in the source code with t() tags.
Can you talk more about the translations in the build step? Is there a reason you're not talking more about that on the site? (Is it just newer, not very reliable/good, or...)?
The idea that I could just throw something like this into my project, not have t() tags in my source code but still get translations, sounds like magic and I think it would be really neat.
Yeah, we've noticed that companies in the early stage ignore i10n completely and then eventually realize it's going to be a huge lift to retroactively support it
So, for the build time translation-
Yeah, I would say it's not reliable yet =p
But, it's not that far off. It's not magic- the idea is that we inject the t functions at build time so that they don't need to be in your code. The vscode extension is a good visual for this- for many patterns, it correctly notices what does or doesn't need to be translated.
But, the real problem is that if a process like this goes awry (a strange pattern leads to text being erroneously translated/untranslated) then it is next to impossible for someone to debug.
Glad you think this is cool. We think this is absolutely on the horizon, and we hope to be the first to get people using it... but in the meantime, we don't want to be responsible for issues on prod...
> companies in the early stage ignore i10n completely and then eventually realize it's going to be a huge lift to retroactively support it
That's the correct thing to do. When you're first building a product you're trying to prove that it can and should exist: that you can get people to pay you money for it. It doesn't make sense to spend your time or money doing anything else.
Once you're successful then you know that people in one country like your product and maybe people in another company will as well. But until you know that, that's the only thing you should be working on.
Yes! I've seen multiple products that were only in English, translations were a super annoying productivity blocker (build step required), tens of unused string keys, keys not matching the it's content etc. Please don't localize until the product is at least 95% "finished".
On this, I just want to share my take-away from my translation engineering days: I fully believe the "right way to do it" is to have two string types: A regular string type and a "user-visible string" type, in a similar way that some frameworks expose a "safe string" vs "unsafe string" (for escaping purposes).
User-visible strings are consistently translatable, and the translation mechanism needs to have deep access in the language for this. I think in typescript this is a fairly doable thing given the AST access you yourself make use of. I'll gladly dig into how you do this on your end but I'm guessing it's somewhere along those lines but not quite?
Incidentally, when you have two string types, it becomes fairly straightforward to detect strings that probably should be translated but aren't tagged as such. Most strings are like this, in fact, because string constants tend to be a bad idea in general (vs numeric constants), and string operations tend to be a bad idea in the context of i18n (you want to use templated strings instead). So you tag until you only have a few left-over.
Yeah, this tracks! The steps are basically 1) determine user facing elements 2) determine strings 3) map user facing elements to the string. (We use the ast and no llms for this)
The upside of this approach is that we get a lot of context for accurate translation. The other upside is that down the line we can pull off fully automatic translation, but as others have pointed out, this is more of a gimmick. We think it's cool but it's more like the cherry on top
Also, yeah, that pattern would make life infinitely easier. Most develors really should think like this already, and not mix user facing strings with strings for other logic. But from what ive seen, pre i18n, devs dont think like this. Someday...
At Roll20 we just released a beta version of our new VTT engine which is powered by Babylon. The devs on the team have really enjoyed getting to use the modern workflow compared to the legacy decade-old stuff we were using before. Thanks Babylon devs!
I don’t actually know how it works for paying yourself. But if you were paying someone else, in 2024 they would get 10k carried over from 2023 and $5k from 2024. You only get 10% the first year. I am not an accountant and this is not tax advice :-)
So you're saying that the advice you got was that if it's a launched product, you can treat software development as an operating expense and just ignore the fact that 174 says software development is an R&E expense?
I mean that sounds great to me...I just also feel like it's probably a very "liberal" interpretation indeed.
The part I'm getting hung up on is essentially, previously R&E expenses (as you note) were a lot more fungible, it depended on a number of factors including how risky the endeavor was. Things that you just do day-to-day in the service of keeping your company afloat (which for a launched SaaS for example would include fixing bugs or even developing basic features) were likely not R&E. Maybe if you embarked on a journey to develop a totally new product, it would have been.
It seems like the most basic reading of this is pretty straightforward: they've taken that decision making away and said "if it's software dev, it's R&E." Not "if it's software dev for a new feature, but hey existing bug fixes and maintenance don't count," just, "software is R&E now always."
Obviously everyone has their own risk tolerance for how they interpret things and what definition they use.
The key is that as long as your interpretation is reasonable, you won't be penalized, and as long as the numbers are fine, you probably won't even be audited. If you have a good representative, you may even be able to convince an auditor that your interpretation is correct.
And yes, I would say that software that isn't continually developed rots, so if you have a launched product, you aren't really working out your technical risks, you're keeping your revenue stream alive. That sounds like a cost of goods sold to me.
Previously, all of our accountants wanted our work to be R&D, which is why we include things like "all software development" in R&D. Now, we may not want it. There are a lot of other places you can put it.
EDIT: CRUD apps have always been on the line between R&D and not R&D, so let's just put our toes on the other side for 2022 and beyond. In comparison, biotech and hard tech endeavors are screwed because that's not even arguable.
1) You can't just go get a loan for "a software" like you can "a widget maker." Most businesses with these large capital assets get loans on them and then it works out nicely as you pay back the loan on the asset while you depreciate it.
2) This would be like the law saying "anything you do in the business of making widgets at all is now a capital outlay" which is obviously ridiculous. It's not that they said "if you buy expensive tools to make software now you have to capitalize them", it's written that any expense at all in service to software development is something now capitalized.
Not that you agree with what's been done and I appreciate your example, but I think it does give a good contrast to see the differences.
I have also been surprised since I found out at the lack of discussion. Based on this post, it seems like many people didn't know. I assume a lot more are going to find out as we get closer to actually filing taxes.
What I've heard is that there's already strong support for changing this but it's just a matter of Congress actually being functional, which political affiliation aside, it's not right now.
This is also the first I've seen this discussed in a tech setting.
I'm glad it made it to the HN front page, but I'd like the desired change to make it into a bill to be passed by Congress before we all pay our 2022 taxes on April 15.
