RumpelstiltskinRSS is a web based RSS reader for your Gengo Jobs RSS. After some one-time steps, you can use any browser on any device to alert you for new jobs. As a bonus, RumpelstiltskinRSS does some filtering for you so you will only be alerted if the size and level of the job meet your preferences, taking the time of day into account.
I optimized RumpelstiltskinRSS for my own needs, but tried to make it so that it can be used by all translators. You can find RumpelstiltskinRSS at http://rumpelstiltskin.appje.nl/rss/. For a description how to use it, follow the Introduction link.
Note that you can set the refresh interval to either 31 or 62 seconds. Use 31 for optimal chances to grab a job, without breaching Gengo's demand to access your Jobs RSS at most twice per minute. Or use 62 to test if RumpelstiltskinRSS suits you, while still running your current RSS reader (set to check at most once per minute) on another device.
330 comments
Happy New Year!
Because of the RSS feed issue Gengo wrote about recently, I made two changes in my tool.
-1- While you can still set the refresh interval to a lower value in your RumpelstiltskinRSS preferences, my server maintains its own cache and will only update it after the 600 seconds Gengo requires. So if you set the interval at 60 seconds, you will see the page cosmetically refresh every minute but only 1 out of 10 times my server will actually contact Gengo's to request fresh information. If and when Gengo announces a shorter interval is acceptable again in the future, I will change my tool accordingly, of course.
-2- Since RumpelstiltskinRSS runs on several servers (rmpl.nl, rmpl-free.nl, rmpl-paid.nl, and two more which I plan to discontinue), there were ways to unintentionally trigger multiple requests (one from each server) to Gengo's server at the same time. From now on, my servers share the information one of them gets from Gengo so this undesirable behaviour is excluded.
The upshot is that no matter on how many devices you run RumpelstiltskinRSS, and no matter what you specify in your preferences, you won't breach the 1 request per 600 seconds limit (unless you run a different feed reader along with it).
Please contact me if you have any questions about these changes.
I uploaded a new Android app version to the Google Play Store. This version can run 'in the background'. (From a technical point of view this is not really true. This 'background' mode is actually a foreground process, but who cares?) Here's the user experience:
- launch the app
- log in to your RumpelstiltskinRSS account
- quit the app
and Rumpelstiltskin no longer blocks you from using your device for anything else. You can launch another app, or put your device to sleep, while a process keeps checking for jobs 'in the background'. You can tell the process is active by the presence of a tiny icon in the status bar. To stop that process, do this:
- launch the app
- log out
- quit the app
and notice the tiny icon in the status bar has disappeared.
This feature brings the app to the level that to my taste is worth a monthly fee, so a near future version will probably be subscription based. However, if any bugs show up due to this 'background' mode I will fix those first, of course.
Chances are I will release the iOS app version in December. Really.
I finished testing and polishing about a month ago. Then came a burst of unrelated projects in my life, and this week I finally found time to focus on the process of actually submitting the app to the App Store. This is not as trivial as it sounds. I have to supply quite some metadata, part of which requires extra work.
I will post a new message once I actually submitted the app, which I hope will be by the end of next week. After that, Apple will probably take a week or two to review the app. Of course, I will keep you informed about their decision, and in the case of approval the URL for downloading the app.
As for the price, on the one hand I don't want to ask money yet since this initial version may have issues that I did not see during testing, on the other hand I don't want to attract people who download anything that's free, causing extra load on my server. So I will set it on the lowest non-zero price the App Store allows. A future version will be subscription based.
One major feature of this version was supposed to be its ability to run in the background. However, it turned out that Apple is very restrictive in allowing this. Fetching info every minute in the background is not possible. As a workaround, I made it such that the app keeps running when you put your device in the sleep mode while the app is in the foreground. This means that even in sleep mode the app keeps checking every minute, and will produce a sound if a job is found, but there is no real background mode. Even when your device is awake, you won't be able to run a different app at the same time.
The other major feature is its stability. In my testing, it always recovers from interruptions in the internet connection or temporary server side failures. So in this regard I am quite happy with its current functionality.
After releasing the iOS app, I plan to create an Android version. On the one hand this will be less work, since I already did the necessary server side modifications and made the major client side design decisions, on the other hand I will need extra time since this will be be my first Android app so I have to learn some basics.
A small step for mankind, but a giant leap for anyone who does not like the default alert sound in the RumpelstiltskinRSS browser version: you can now use an alert sound of your own.
To do so,
-1- create or download a sound file on your local disk;
-2- upload it to my server using the relevant link on your preferences page;
-3- set your preferences to use this custom sound.
See also the "Can I choose a different sound?" section on my FAQ page, or contact me if you have any questions.
Hello, writetoatsushi,
Good to hear you like my tool - as long as it works. :-)
My first guess is your account has been automatically deleted since my server saw no activity during an extended period. You can solve this by creating a new account on rmpl.nl. Even if you use the same account name and password, you may have to log out and back in again, or even uninstall and reinstall the app. If this does not work, please contact me directly so I can have a better look at the issue. Sorry for the inconvenience.
On a different forum, Gengo announced the minimal refresh interval has been lowered from 600 to 480 seconds. I modified my tool accordingly. You can set the interval in your RumpelstiltskinRSS preferences at 60 seconds and my tool will still meet this 480 seconds limitation (by reusing its own cache in between).
As Gengo announced today the the minimum refresh interval has been lowered to 300 seconds, I modified RumpelstiltskinRSS accordingly.
If you saw a very long error message in RumpelstiltskinRSS recently, it's unrelated to Gengos error message about multiple requests, and I believe I solved it so you should no longer see it. If you still get an error message, please contact me about it.
RumpelstiltskinRSS now marks jobs for which you are a Preferred Translator with a star and the code PT. Also, you can now set separate preferences for jobs for which you are a Preferred Translator.
Update about the Android version: after spending far more time than I had expected on getting familiar with the basics of Android app development (Android Studio is powerful but overwhelming, and the way code is organised is not immediately clear), I am now making fast progress in the actual coding of the app. I will probably publish an initial release in the course of July.
Today, one user notified me that when RumpelstiltskinRSS finds a job, the corresponding link is redirected to the dashboard.
I tested it with a job in my own feed. The correct link starts with https://gengo.com/ (note the s in https), but the link RumpelstiltskinRSS uses starts with http://gengo.com/ (http without s). This worked fine in the past, but apparently, Gengo now requires https.
I updated the scripts on my server to meet this requirement. If you still experience this (or any other) problem, please let me know.
Part of the current RumpelstiltskinRSS functionality is that if you work in multiple language pairs, you can specify different preferences for each pair. While this seemed a good idea when I first implemented it, I am not so happy about it anymore, so I plan to disable it.
Please let me know if you rely on this feature and I will keep it enabled for you. For all others, I will disable this feature by the end of this month.
Hi Lara,
Thank you for the extra information. I don't think RumpelstiltskinRSS has been entirely down, at least not when I read this post by supeinjin01, because the first thing I did was a short test how it worked for me (it showed a few jobs).
However, in the log files I occasionally read about problems reaching Gengo's server. Perhaps these issues are related to slow connections anywhere between Gengo's server, rmpl.nl and the end user.
If I hear about more people experiencing similar problems, I will have a closer look at it.
One user reported recently that at times the Android app version of RumpelstiltskinRSS stops functioning abruptly. You can tell this has happened if the "Next check: ..." time is incorrect. (It should be close to the current time. If it is, say, one hour ago, then the app has stopped functioning at that time.)
I checked the Android developers documentation and found that as of Android 8.0 certain restrictions apply for processes like the one I use to keep the app in touch with my server. Fortunately, the documentation also says how to make the app compliant with these restrictions.
Most likely, I will publish an updated version within 1 or 2 weeks.
I changed the server scripts to improve the calculation of the the "Next check:" time.
It used to be simply "last time + T seconds", with T=31 or T=62 as set in your preferences. This has some unexpected downsides.
First, now that RumpelstiltskinRSS runs on multiple servers, this simple approach caused synchronization problems. If you ran the iOS or Android app version, which is tied to rmpl.nl, as well as the browser version on rmpl-2020-3.nl/paid, you could get a notification via the app while the browser still said 0 jobs.
Second, "last time" is ill-defined if the interaction between your computer/device and my server, or between my server and Gengo, takes more than a few seconds. One user recently saw that it took over 20% more than 31 or 62 seconds before the page refreshed. While it looks like this was only a temporary issue, what happens once to one user will no doubt happen more often to many users.
Third, it is left to chance how many translators refresh their page more or less at the same moment.
Therefore, I changed the calculation into "T_0 + N x T seconds", with T_0 a per translator fixed point in time and N the lowest whole number such that the calculated time is in the future. T_0 is derived from your Jobs RSS in a way that as far as I can see results in a more or less even distribution of all T_0's.
If you want to know the details: the unique part of your Jobs RSS is a string of hexadecimal characters 0-9, a-f. I use this more or less random number to pick for T_0 a more or less random (Unix time) value between 0 and 61.
This approach solves the first two issues and alleviates the third one. First: the same calculation on each server, using server-independent parameters only, results in perfect synchronization. Second: while any delay due to slow connections or high traffic load may shift the moment the page is actually refreshed, a consistent delay will result in a consistent shift so the refresh rate is not affected. Third: it's still possible that the T_0 value for several translators in your pair is close to yours, so throughout the day you will clash with this same group, but as far as I can see the extremes are less extreme than in the previous approach.
The upshot is that RumpelstiltskinRSS will more reliably refresh every 31 or 62 seconds, and the refresh moments are spread more evenly over all users.
After receiving the first few donations (many thanks!), I realized a lot of personal data is involved. PayPal gives me your full name, your email address, and in some cases also your physical address.
One of these days I will add to my site(s) a privacy statement to the effect that I won't store these data on my server or share them with anyone else.
I haven't decided yet what I will do now that these data are in my mail on my local computer. While it should be possible to set up a workflow in which I no longer need the messages after processing the payments, in the current stage I don't feel comfortable to erase them right away.
As for the email address, I can think of situations where it could come in handy. In the privacy statement I will describe these situations, and at the Donate page I will ask if you allow me to use your email address for these purposes.
In my tests this weekend, rmpl.nl still performed bad, despite the step I announced in my previous post. After much debugging, I found a quite trivial cause: I had somehow overlooked a huge number of users whose account exists on rmpl.nl only, so they are still allowed to use that server in the browser version, and while not all of them actually did this weekend, the total number of active users there is still far more than the number when the problems started.
In the next few days, I will further polish my semiautomatic administration to determine the status of each user (paying or non-paying; presence on each of the servers), and try to automatically copy the accounts that exist on rmpl.nl only to either rmpl-2020-1.nl (for non-paying users) or rmpl-2020-3.nl/paid (for paying users), so I can also move this group away from rmpl.nl.
Talking about paying users: about a quarter of all who did the survey recently and promised to make a donation actually did so far. I would appreciate if more people do so, so I can base my future plans on the real rather than estimated budget.
Alexander,
Thank you so much for your quick response. I did both things: I started a new account at rmpl-2020-1.nl and also sent you a donation to the other paid site. Please let me know when my account is valid there.
Thank you for everything you've done for this community!!
Regards
Alicia
It can't hurt to reach out to Gengo support so they are aware the server is slow in responding at that moment. If more people do so, perhaps Gengo can see a pattern under which conditions this problem arises, and in the long run do something about it.
However, most likely all translators in your pair experience the same problem at the same time, so in the end your chances to grab a job won't be affected. The only thing that really matters is how many jobs per translator there are in your pair.
If 100 translators rush for the same job, 99 will miss out on it, no matter if Gengo's server takes a split second or several minutes to decide who's the lucky one. If Gengo makes the server more responsive, you will just have a smoother "you're too late" experience. :-)
Some users of the browser version have contacted me recently because they got an error message about a problem setting up a secure connection.
If you have the same experience, a simple workaround is to visit http://www.rmpl-free.nl directly. Make sure to use http://... as opposed to https://.... (ending in -s) so your browser does not try to set up a secure connection.
As a rule of thumb, it's always a good idea to use a secure connection (https//...), but since RumpelstiltskinRSS does not exchange privacy sensitive data with your computer, it's okay to use an insecure connection in this particular case. (And since this is about the free version, I am not going to solve this issue by replacing the apparently invalid certificate by a paid valid one.)
As an aside, please note rmpl-free.nl uses its own preferences. There is no synchronization with your preferences on rmpl.nl.
Like I wrote on August 15, after a trial period a fee will be mandatory if you want to keep using the web version of my tool. If you don't pay in time, it will show a reminder on the jobs page rather than informing you about any jobs.
However, I changed my mind about the app versions, because I believe Apple and Google only allow asking a fee for app usage if that fee is paid from within the app, and I am not ready for that. So if you want to use the app version only, nothing changes. You pay for the app itself, of course, but other than that you can keep using it for free (unless and until I implement mandatory fees as in-app purchases at some point in the future).
For now, the fee I ask is basically USD 20 per year (after a 3 month free trial). Between now and December 31, 2021, some transition rules apply, which I will not explain here in detail. (They are not secret, but they are too boring to elaborate on.) If you use the web version (rather than the app, or along with it), you will see a message on your jobs page that summarizes the upshot for your specific situation. Just contact me if you want to know the details.
The message only tells you the deadline to pay, not the amount I ask, nor your payment options. I plan to modify and rename the Donate page for this purpose, and insert a link to it in the message. You already can make a "donation", which I will count as a fee for at least the time up to December 31, 2021, but it feels weird to write explicitly in the message "please make a mandatory donation".
After you paid, I need to do some manual processing before you will see it reflected in the message on your jobs page. I will try to do so within 24 hours after the payment.
This weekend, I found rmpl.nl had stopped functioning. The problem seemed to be related to the code that communicates with my Payment Service Provider (Mollie), so I disabled that. For now, you can only pay using PayPal. If you cannot or don't want to use PayPal, please contact me directly.
Since Mollie payments have advantages both for you (more payment methods) and for me (simpler automated administration), I plan to re-enable it in the near future, though it's hard to say exactly how much time I will need.
Yesterday was the first day a fee for using the web version of my tool was mandatory (unless you started using it less than 3 months ago). If you did not pay in time, the service should be blocked. However, while in my tests everything worked fine, it turned out that the service was also blocked for users who did pay their fee.
As a temporary solution, I extended the trial period. So whether you paid or not, you can keep using my tool until I fixed the bug, which will most likely be within a few days. If you already paid, I will shift the end date of the period you paid for accordingly. E.g., if you paid USD 5 and I fix the bug tomorrow, your payment counts for the time up to January 3, 2022 rather than December 31, 2021.
The problem seems to be related to me changing my mind about the rules for app users during the time I wrote the code. Since I am an app user myself, my tests did not reveal this issue that is specific to paying users who did not buy my iOS or Android app.
BTW The preferred way to pay is on http://rmpl.nl/?pay, where you will be redirected to my payment service provider Mollie. Mollie payments have advantages both for you (more payment methods) and for me (simpler automated administration). You can also use the Pay link on one of the other servers, but there the only option is PayPal.
I believe I fixed the bug, yet I want to do some extra tests. The first day a fee is mandatory will be next Sunday, October 10. If you already paid, say, USD 5, that counts for the time up to January 9, 2022.
Again, the preferred way to pay is on http://rmpl.nl/?pay.
Just contact me directly if you have any questions.
Hello Damián,
From a technical point of view, yes, you can. It's against Gengo's rules, though, to access your feed more than twice per minute, so you would have to set a low refresh rate for each reader. That said, I believe Gengo is not very strict at this rule.
No, I never used the Gengo power-up version of Feeder.co so I can't comment on it other than that there's no such thing as a "power-up" on a feed reader. The communication between your computer and the server is as fast or as slow as your internet connection, and Gengo uses a per translator cache so the info is refreshed at most once per minute no matter how frequently you access your feed, even if you use multiple feed readers.
So using a different feed reader than RumpelstiltskinRSS, or even using multiple feed readers, does not give you an advantage in terms of speed.
Hello Damián,
Thanks for trying my tool. There used to be 2 options: 31 of 62 seconds, but I changed that some time ago. Now you can set (on your preferences page, under "Jobs RSS") any interval, as long as it's at least 60 seconds. Due to Gengo's caching, less than 60 seconds simply doesn't make sense.
While the software attempts to refresh at the rate you specified, there may be fluctuations due to all kinds of unpredictable circumstances on the internet. If you find the page sometimes refreshes within a minute, you may want to use a slightly longer interval.
If you are using RumpelstiltskinRSS on rmpl-free.nl, there is a small chance the service will be interrupted a few times in the next 24 hours.
The reason is the scripts use PHP 7, and my provider announced they will not support that version any longer, so I have to switch to PHP 8. I already tested on a different server, and found some changes were necessary to make my scripts compatible with PHP 8 on that other server. In theory, the modified scripts should also work on rmpl-free.nl after I press the OK button to use PHP 8, but in practice it's possible I will need to make a few more changes, and while I am working on that the service could be interrupted a few times. If that happens, I apologize in advance for the inconvenience.
Hi!
Thank you very much indeed for the amazing RSS reader! This is the very reader I've been looking for!
I have one question. When I use this on my iPhone, it does show new jobs but doesn't make any sound.
Is it possible to let me know by sound??
Hi Hemehemekukohi,
RumpelstiltskinRSS is supposed to produce a sound when it sees a job matching your preferences, no matter which browser you use. I run it without problems on an old iPod (iOS 2!) and on a MacBook with recent software (OS X 10.7, Safari 6).
I think this is either a trivial issue with the settings on your device (low sound volume) or a subtle issue with the iOS/Safari version you use. If more people report this problem, I'll have a closer look at it.
Hi Alexander,
Thank you for your quick and informative reply.
Although I checked every setting which comes to my mind including sound volume, it still doesn't produce any sound.
It would be very grateful if you could have a look at it when you have time.
When it sees a job on my iPhone, it shows a music player (?), which I've attached the photo of.
I use iPhone 5c (iOS 8.3/Safari 8), just in case.
Thank you.
IMG_0341.PNG