In your second-to-last paragraph, you identified the most important question: "How will it know?" And the answer is that "it cannot know."
The information to associate "Product_with_specification_one" to "prod_id=767" and to determine Bulgarian/English language selection is not available in the requested URL, and so is not available to mod_rewrite.
The only information that mod_rewrite will have available to it is in the "/products" part of the requested URL-path. This dictates the solution, which is:
1) Change the links on your HTML pages from "http://www.example.com/product_info.php?prod_id=767&id=36&language=Bg" to "http://www.example.com/products/Product_with_specification_one". This can be done by modifying your script to pull the "friendly" URL from the database instead of getting the "unfriendly URL with the prod_id in the query string" as it does now. Or you could add code after the script gets the unfriendly URL to do another lookup to "translate" that unfriendly URL to the friendly one.
The first method works better if all the data is in one database, while the second method would work better if you decided to put the URL translations into a second database. Generally, it will be easier to maintain your site with all the data kept together in one database, but I do not know anything about your existing script, and so have to present both options.
2) Write a mod_rewrite rule to internally rewrite all requests for URL-paths beginning with "products" to your script (or to a new "wrapper" script, which makes the new-URL-to-product id association and then "includes" your original script).
You will need to pass the "Product_with_specification_one" part of the requested URL-path to this script, or have your script get it from the server variable containing the client-requested URL. In this script use the "Product_with_specification_one" part of the client-requested URL to look up the correct product-id (prod_id=767), and then proceed as before.
3) Detect direct client requests for the old "http://www.example.com/product_info.php?prod_id=767&id=36&language=Bg" URLs (which are now used only as internal script filepaths), and externally redirect them to the new friendly URLs. Again, this will have to be done using both mod_rewrite and your script, because again, a database lookup will be required.
The mod_rewrite code for step 2 is rather trivial. For the "pass friendly product name as parameter to your existing script" approach, it would be something like:
RewriteRule ^products/(.*)$ /index.php?product_name=$1 [L]
So, as you can see, several modifications and additions to your script will be needed. If possible, these should be done within your existing script. However, if you use a commercial script which is updated frequently (to add features and improve security), then the idea of using a "wrapper" script will likely be more attractive. In this way, the commercial script can be left as-is, meaning that you can upgrade it any time you like, while the "wrapper" script that calls it can be used to make the "custom changes" to the input parameters.
However, it is still likely that you'll want to make the changes to publish 'friendly' URLs on your HTML pages inside the main script, because doing it any other place may be too difficult or inefficient. So, these changes should be kept all together in one area of the script, and be well-documented, to make "patching" the upgraded script easier.
Jim
