Yunchao Guan's answer is correct.
For example, i recently unpacked an application (zaka.com.amperemeter-1.apk, yes, it's zaka.com, not com.zaka as it shoule be) to improve the bad German translation that had been done by google translate.
Unzipping the .apk, using dex2jar on the .dex, and procyon on the resulting jar gave me, for example:
unzip/procyon/gluapps/Ampere/meter/Activity/MainActivity.java:240
return this.getString(2131099670)
ALSO, procyon gave me an R.java that has a name for that number:
unzip/procyon/gluapps/Ampere/meter/R.java:909
public static final int Usb_plug_type = 2131099670;
So you really should get a R.java source code from decompiling. In case you don't, apktool d zaka.com.amperemeter-1.apk
gives you several files that have the same number, in hex, in smali files:
work/smali/gluapps/Ampere/meter/R$string.smali:20
.field public static final Usb_plug_type:I = 0x7f060016
work/smali/gluapps/Ampere/meter/Activity/MainActivity.smali:477
const v1, 0x7f060016
these are basically the same as in the decompiled java files. Additionally:
work/res/values/public.xml:473
<public type="string" name="Usb_plug_type" id="0x7f060016" />
This is the key that maps to the actual, translated, string in the language-dependent file:
work/res/values-de/strings.xml:25
<string name="Usb_plug_type">USB</string>
So, with a normal apk, if you use unzip/dex2jar/decompiler/apktool correctly, everthing should be there. If not, it would be best if you provided a link to the apk, because something weird might be going on with yours, but there's no way to tell unless you give us a chance to look at your specific apk.