Does Apple provide developers a set of standard terms in differing languages? The reason why I ask is that I'm having portions of my application localized and want standard terminology consistently applied throughout the app. I have utilized some tactics to do this with terms like 'Loading...' by changing the language on my device and observing how Apple has interpreted those terms in other languages. This has only gotten me so far however, and a resource that I can give a translator would go a long way in creating a seamless experience with the consistent application of terminology.
It has been two and a half years since posting my radar, but Apple has finally posted its iOS glossaries:
You can download them from developer.apple.com, or use this link to quickly find them:
https://developer.apple.com/downloads/index.action?name=Glossaries%20-%20iOS
EDIT 29 FEB 2020: This link is still valid and the glossaries have been updated on 15 JAN 2020 with everything updated for iOS 13.3.
At WWDC this year I went to the Localization Lab to get an answer to this question, since a bona fide answer from Apple was needed.
From one of their head cheeses in localization he told me that currently there are not any publicly available resources for download for iOS or Snow Leopard. He did tell me, though, that these resources were slated for release in the coming weeks after WWDC.
This answer will be updated when the information becomes available.
UPDATE 19 JUN 2012: Wow, it has been a whole year now! Obviously Apple didn't come through for us 'in a few weeks'. I did talk to them again this year and was given a contact to follow up with via email. I explained that they made a claim to have it last year and this was the response I got:
I did check with the documentation folks and found that they're still
planning on doing this but it's fallen behind other priorities. If you
haven't already done so, would you mind filing a bug report about
this? That's one of the best ways to convey the desire to the
appropriate people. While I've relayed this feedback to some people
it's always best to have a bug report directly from folks outside of
Apple. Feel free to forward me the bug number and I'll keep an eye on
it.
Our best bet at this point is to keep filling bug reports so that this gets more attention. Just for the record, I did file a bug report last year.
Apple provides a number of translation resources that you can download which may or may not be useful. One of these is AppleGlot, a tool for replacing strings in application resources. A number of XML-based glossaries for different languages are also available, but they're specific to AppleGlot. You may be able to make AppleGlot work for you, or you might just want to extract what you can from the language glossaries. AppleGlot and the glossaries were created to support translation of MacOS applications, so the terms are related to MacOS X and not iOS. Nevertheless, I think it's worth a look.
Related
First
No I am not asking you to teach me hacking, I am just curious about this file and its content.
My journey
When I dived into the new HTML5 Boilerplate I came accross the humans.txt. I googled for it and I came at this site http://humanstxt.org/.
Immediately my attention went to this picture:
Do I read this correctly? Hackers.txt?
So I resumed my journey in google and stopped at this articles
When I started reading this I had the feeling that its about the difference between Hackers and Crackers. Later I got the feeling that I'm might be wrong and that this place is that this hackers.txt file is a sort of guestbook for hackers?
Also other examples about hackers.txt files I found here
Some files contain code, others have just hurtfull information.
Now I'm realy confused, guestbook, hack tutorials or just history?
Question
What is the use of this hackers.txt file?
The way I see things:
robots.txt contains information and instructions for robots (so it should be read/used by web crawlers, spiders and other kind of bots)
humans.txt contains useful information to be consumed by humans, according to http://humanstxt.org/
hackers.txt should be targeted towards hackers, so it should contain any information the site owner might want to transmit to a hacker, as Ze'ev pointed out. I don't think this should be a place for hackers to write anything, but rather to get information from the site owner (perhaps on how to report vulnerabilities, as others suggested).
Commonly known as Eduardo Vela, Eduardo A. Vela Nava (or sirdarckcat on Github and Twitter) has been a Security Engineer at Google since 2010. (He currently has the role of Product Security Response Team Lead).
As other security experts before him, he pondered the issue of effectively communicating the details of a site's vulnerability reward program to white hat hackers/pen-testers.
One specific such person is Chema Alonso (also on Twitter).
He is well-known enough to warrant a Spanish Wikipedia entry
Between 2005 and 2011 Alonso was awarded the Microsoft Most Valuable Professional Award for Enterprise Security 6 years in a row. That should tell you something about his "skillz".
On February 3rd 2011 Alonso wrote about his frustrations regarding the topic of communication between the administrators and/or developers of a site and hackers.
He proposes a similar initiative as humans.txt but for hackers. As he mentions this hackers.txt initiative in his blog-post.
In April 2011 The humanstxt.org website got a new design which includes the image which mentions the hackers.txt file.
At this point, I must sadly submit to conjecture, but... consider:
The team behind humans.txt are all from Spain (mostly Barcelona)
At this point Alonso is already quite well known in the Spanish developer community
Would it be such a far stretch to imagine that they got to know of each other's efforts?
On May 14th 2014 Vela, already working at Google, commented on a blog-post by Alonso. It is most likely that they had further contact in a professional setting. Whether or not thay extively shared their idea's regarding anything related to hackers.txt is unknown.
On July 6th 2017 Vela posted a question to this extent on twitter:
How about we create a /hackers.txt that says whether something is in scope or not of a vulnerability reward program and where to report it?
Subsequently, an empty git repository was created for hackerstxt.org on github
and an email thread was opened at Google Groups to discuss this idea further.
On August 13 2017, Edwin Foudil (or EdOverflow on Github and Twitter) created a git repository for security.txt on Github and responded to the mailing list:
I have published a similar project to the one being discussed in this group (https://github.com/EdOverflow/security-txt) and would love to get some of your feedback and ideas.
The project is the equivalent of robots.txt, but for defining a security policy. Companies can add a security.txt to their website and define clear guidelines of what security researchers must do when they discover a security issue. security.txt also allows bug bounty programs to add their scope there. security.txt uses a similar syntax to robots.txt, which should make it easier for machines to parse.
He was, in part, inspired by an open-source project he was working on at the time called GratiPay. GratiPay had a SECURITY.txt file since 2013.
His inspiration also drew from the SECURITY.md files that more and more open-source projects were adding to their repositories.
On September 10th 2017, Foudil submitted a first draft for security.txt to the Internet Engineering Task Force.
On September 14th 2017 Alonso wrote a blog post with the title (translated from Spanish) "Security.TXT an IETF draft for my Hackers.TXT".
Beyond the title, Alonso does not allude to the fact that his 2011 idea was the origin of the draft but he does state his approval of the effort.
On February 3rd 2018, the mail group was informed to concede to security.txt and Vela tweeted that Google had already implemented one.
Further information
Details and a nifty tool to generate your own security.txt can be found at
https://securitytxt.org/
Adoptation
Even though the RFC is still in draft, the standard is already being adopted quite well by major players on the web.
Besides the security.txt at Google, there is also one on the website of:
1password
BBC
bit.ly - http://bit.ly/security.txt (can't be linked because StackOverflow blacklist the use of common link shorteners in posts)
CERT NZ
DailyMotion
Dropbox
Facebook
Github
haveibeenpwned
NodeJs
NPM
Open SSL
Shopify
(Feel free to add more from well-known sites, if you find 'm)
As with humans.txt, there also seems to be a hackers.txt site at http://www.hackerstxt.org/. I'm not sure if someone has set the site up as a joke or not, but it links to a blog post on someone's Blogger site.
The post rambles on a bit (I put it through Google Translate) about the poster's history as a 'hacker'. Anyway, towards the end the writer says:
therefore believe we should promote an initiative type hackers.txt , in which managers leave us a message to potential "aliens who are good" that makes it clear they will do managers receive a report of a vulnerability in your site. I've been circling this , the truth is that it is difficult to finish shaping, because perhaps some "alien who is not so good" , type Brainiac , take a free hand to brush a site, or the "good board administrator" , decide to change your mind and Liem, but I think we should be able to do something, I dunno, maybe having Jon Jonz , or perhaps thinking about how to write that file hackers.txt . How do you see it? Greetings Evil!
So I assume that the poster wants to start a sort of hackers.txt standard in the vein of humans.txt, but hasn't finished it off, or hasn't gotten it into the English speaking world.
Digging around, the Blogger site seems to be owned by a guy called Chema Alonso, who must be fairly reputable in the world of Spanish programmers as he has about 35k Twitter followers (https://twitter.com/chemaalonso). He seems to work for a company called ElevenPaths (http://elevenpaths.com/), which says that it's driving "radical innovation in security product development". A quick Whois check shows that the hackerstxt.org domain is registered by someone in Madrid, so I would assume it's Alonso.
The .txt file over at http://www.textfiles.com/news/hackers.txt, which has been refered to by some of the other answers in this thread, doesn't seem to have anything to do with the hackers.txt reference over at http://humanstxt.org/, and neither do most other search results for 'hackers.txt'.
It's possibly a joke, but If humans.txt is for humans to read then maybe hackers.txt is a warning for hackers.
Like the notice you get when you SSH into some more public terminals. "You are being watched... we will get you if you do anything bad..." That sort of thing.
If a hacker did compromise the site, the might notice the file, read it, realise you mean business and be scared away!
Interesting idea.
As this question is somewhat open, I think you are also expecting some assumptions, I write here (not in a comment) my opinion, but if it should be there, I'm sorry.
I think that the idea lying behind humans.txt (which I heard of before) is to make a new habit, new style or something like that. In fact, you can put a contact page, where all these data from humans.txt can be put. I think that hackers.txt could be also something like new style.
I suppose that hackers.txt was much earlier, maybe for 20 years, when www servers and popular web knowledge was poor, when using localhost Apache+PHP+MySQL was making you "a hacker", and if someone could access the file other than index.html (and linked pages from this), reading hackers.txt was some kind of prize, or maybe some kind of filter to show some information to "those who behold" (like this one perhaps).
I think hackers.txt should contain notes on how the site owner would like for data to be used... E.g. "I don't mind if you scrape the movie listings, but please don't hot link out images in your app"
I am planning to add weather report for selected country->state->city, for daily, weekly, monthly averages. I have googled it and also went through couple of discussion on stackoverflow threads and I got confused! Could anyone please tell me if there is already Weather report APIs library available? What could be the best way to implement my requirements? I am just expecting overview so that I don't chose wrong path.
Thanks.
See WorldWeatherOnline.
I compiled a set of information about different weather APIs looking for a similar solution. My general consensus was the WorldWeatherOnline seemed to be the best bang for the buck (free) and seemed pretty feature rich.
http://michaelwelburn.com/2011/11/02/comparing-weather-apis/
UPDATE (12/18/2013): This response was from 2011, since that time some different providers have made updates. I tried to keep the link semi-up to date, but you'll want to take the list provided and do your own research.
I was just wondering about the pros and cons of submitting metadata and changing the UI buttons for people who don't speak English.
According to this study there isn't a huge percentage of users who go to stores that aren't in English (all the smaller countries have stores in UK English).
That said, I was wondering if maybe there is some advantage to this? For example, if I submit to the French store I would assume there are less apps with metadata in French and so therefore you might have a better chance of getting featured.
Keep in mind my app is super simple with no network activity and only a couple of buttons I would need to translate.
PS please forgive me if this is not an appropriate question for this site. And feel free to vote to migrate.
There is no disadvantage of providing localised versions of your application. It's probably more a question of knowing your target audience.
Generally one should assume that in a country, which official language is not English, people don't speak English. Of course there are exceptions like Germany were a lot of people do speak English. But usually they still feel more comfortable using their native language. Following your example, French traditionally have a very strong opinion when it comes to languages and will appreciate a French localisation.
Besides users by country you should also take into account the area or business segment you're targeting. Just to give an example: an British pub guide obviously is targeting English speaking people. If you're creating something around renewable energy it could be worth exploring a German version besides an international English one, too since it's really popular in Germany and also supported by government subsidies.
If you can reach your potential users in English a localisation might not be necessary. But the lack of localisations will make it definitely harder to advertise your application. I can't think of an non-localised app have been featured on the German App Store. This might be just bad memory but Apple points out the importance of localisations many times in the documentation.
Since you mentioned your application doesn't actually have that many localisable elements it might be worth the effort anyway. Even if you decide not to do so for the initial release it's worth building your application with future localisation in mind to add localisations in later updates. See that post for more.
There is a disadvantage, and it is that once you add a language, you will be expected to continue supporting it in future releases. It's not nice for someone who uses your app in say Chinese to install an update and find that the app has reverted to English or that some new features are not translated. But in order to continue supporting a language in future releases, you'll have to get new/changed content translated which will cost you (assuming you are paying a translator) and delay your release a little. You'll also have a bigger testing burden.
That said, localization is a great way to attract more users.
I'm scratching my head over this.
I have a moderately successful app which has a free "LITE" version in addition to the full one. This is a utility app, not a game with levels, and I'm having trouble figuring out what Apple will accept for the lite version. The reason this is now an issue is that I've brought both code bases together with different targets and my new improved lite version will be iPad compatible as well.
There are two fundamental differences in the versions. In the lite version, the data displayed is only displayed for the current day, whereas the full version allows users to choose any date. Additionally, one of the data screens shows 3 data points in detail, whereas the full version shows much more. The lite version is perfectly functional in its own right and has no greyed out features.
What I would like to do is use the spare space on the lite version data screen to explain that more data is available in the full version and offer a button to upgrade, however I can't figure out if Apple will classify this as "upselling" (well how else am I going to mention the full version?) and from reading the new app store review guidelines, I was disappointed to note that absolutely no further clarity seems forthcoming from Cupertino in this regard. All the examples I find from Apple are games with additional levels and this simply doesn't match a "utility" application.
Is there any recent advice on what is and what is not allowed? I'm aware of not having greyed out functionality and nagging the user - but does having an upgrade button on one of the tabs (in the case of the iPad in a popover) count as nagging? Am I allowed to mention the additional features in the premium version or does that count as upselling? If not, what can I actually say?
Clues welcomed!
Frankly speaking, there is no way to be 100% sure without submitting the app. There might be someone who have already tried this and get rejected. It's not very easy to be sure. But as a user personally I won't be happy to see the upgrade button in every page. Rather I would like to get the summery of full version in a different page. This might not be a better design to have an upgrade button in every page, though this is my personal opinion. Apple gives importance to be consistent with the convention, and the convention is to have different upgrade page, I think.
You can download a number of lite apps and check whether any one has done this kind of thing. The policy should be same for both game and utility. If after checking many you don't find a single one, then you should reconsider this. But yes, you can't be 100% sure.
The rules appear to be inconsistently applied.
I think it boils down to the perceived difference between "Ha! You don't get $feature unless you pay us!" and "By the way, we also offer $more_expensive_app with more features." The two are effectively the same thing, but they leave a different impression. Yes, it's a big grey area — I've seen apps across the spectrum (I don't recall any persistent nagging/mentions, but certainly "buy $full_app to get more levels").
"Other apps by $company" might be a good way to go, perhaps in an "about" tab or similar.
Reviewers are also far from consistent. Before Apple did any "private API" checks (they didn't seem to until mid-2009; apparently not even the frameworks you linked to which is dead easy), private API usage was determined by whether your app did anything in $list_of_suspicious_behaviour, which seemed to be applied inconsistently by different reviewers.
I've also used "$full_app" because that's the impression I got; I think part of the guidelines is that you're not supposed to give the impression that your app is not "full". I also hate crippleware (artificially limiting a feature, e.g. a navigation app limited to 8 waypoints and telling you to buy the full version if you want more, as opposed to simply not including a feature), but Apple doesn't seem to mind.
Apple allows ads in apps if they are presented in a reasonable manner.
Developers can choose which ad network to run, even from competitors such as admob.
There's nothing to say you can't be your own ad network.
Just make sure your ad for your products (which occasionally just so happens to be an ad for the full version of the same app) follows the same presentation rules as the ads for admob, iAd, etc. follow. Your own ad network may or may not be the campaign you choose to run during the review period.
I was recently asked by a Team Leader (not mine) if I would be willing to undertake a programming project. The members of his team are currently pre-occupied with other more important projects. I graduated college two years ago, and up until now programming has only been a hobby of mine. Recently I decided that I would like to pursue a career in software development. I accepted his offer so that I can gain some real-world experience and start building a portfolio.
In about an hour I'm scheduled to meet with the Team Leader to discuss the details of what he needs. From a short e-mail exchange with him, I know that the base project is to update an existing ASP.NET form—but I also think there's more to it than that.
Considering that I'd like to eventually put this project in a portfolio, what kinds of notes should I take at the meeting?
Take whatever notes you can that will best help you understand the use cases and the user requirements. Everything else is just technical details that can be figured out later.
I graduated college two years ago, and up until now programming has only been a hobby of mine.
In that case, my suggestion is:
revel in your ignorance.
Make the most of the fact that you know nothing and you're being given an opportunity to learn - abuse the chance to ask as many questions as possible of the Team Leader in question regarding what type of questions you should be asking and how you should be documenting what you learn.
You only get one chance to be ignorant, once you've wasted it you have to spend the rest of your life as a know-it-all; take the chance to enjoy the learning process.
Get a list of people who are the intended users. Talking with them will allow you to flesh out the overview that the Team Leader gives you. It is likely that the intended users have a very different understanding of what the app is supposed to do than the TL does. So you'll likely be going back and forth for a while. It's well worth the effort though because you'll do much less re-coding.
Try to understand that the Team Leader him/herself might not even have all the requirements available right at the beginning. Be prepared to be hunting down people and writing all these requirements down as they come in.
Things will change during development, new problems and new requirements will always be popping up.
Three things:
What: What is the software supposed to do, the more detailed you can manage to get the other person to be, the better.
How: Are there any known constraints? For example, if it has to ask for a telephone number, does it have to validate nationally/internationally/not at all. Does it have to run on Windows 2008/2003/all
Who: Two sides:
Who will answer any questions you'll have, will you setup weekly progress meetings?
Who will use the software, can you get their early input on your prototypes, can you ask them for opinion/requirements?
One thing I've found very helpful is carrying a hard-copy of any existing requirements (use cases, wireframes, whatever) or any other potentially useful information in a 3 ring binder to any project meetings I attend. If the meeting strays off topic or questions about previous discussions or documents come up it is very nice to have the information at your fingertips in a format you can make notes on, pass around the table etc.
As a bonus, I find most people don't carry any documents to meetings, so you'll also end up looking like you are a real go-getter who is always prepared, which is never a bad thing.
Main downside to this is that you'll waste paper if the documents are updated and changed frequently.
Find out the where as well, where are the files you need stored on the network, where is the source control repository for the project, etc.
Since this is your first taste of doing a real world project, please please please make sure you use source control even if you are the only dev on the project. Your co-workers will thank you and you will thank you the first time you need to back out a change that didn't work.